Test emulator, test module emulator, and record medium storing program therein

ABSTRACT

There is provided a test emulator for emulating a test apparatus including a plurality of test modules for supplying test signal to devices under test respectively, including: a plurality of test module emulation sections for emulating the plurality of test modules generating the test signal based on different cycles, a control emulation section for emulating a control apparatus for controlling the test of the devices under test, a synchronous emulation section for generating test signal generating timings, at which each of the plurality of test module emulation sections is to generate the test signal in simulation corresponding to cycle time of the test module emulation section, based on instructions from the control emulation section, a timing alignment section for aligning the plurality of test signal generating timings generated by the synchronous emulation section in order of time, and outputting them one by one, and a schedule section for causing the test module emulation section corresponding to one of the test signal generating timings output by the timing alignment section to generate the test signal in simulation in the cycle time corresponding to the test signal generating timing.

The present application is a continuation-in-part application of PCTapplication No. PCT/JP2004/001648 filed on Feb. 16, 2004, which claimspriority from Ser. No. 60/447,839 filed on Feb. 14, 2003, 60/449,622filed on Feb. 24, 2003, Ser. No. 10/403,817 filed on Mar. 31, 2003 andSer. No. 10/404,002 filed on Mar. 31, 2003, the entire contents of whichare incorporated herein by reference.

The present invention also relates to a U.S. patent application Ser. No.10/404,002 filed on 31 Mar. 2003, a U.S. patent application Ser. No.10/403,817 filed on 31 Mar. 2003, an International Patent ApplicationNo. PCT/JP2004/001649 filed on 16 Feb. 2004, and an International PatentApplication No. PCT/JP2004/001648 filed on 16 Feb. 2004, which isincorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a test emulator, a test moduleemulator, and a record medium storing program therein. Moreparticularly, the present invention relates to a test emulator, a testmodule emulator, and a record medium storing program therein foremulating test apparatuses including a plurality of exchangeable testmodules for supplying a test signal to DUTs respectively, and verifyinga test environment without using real things such as a DUT or a testmodule.

2. Description of Related Art

Conventionally, technologies are disclosed in Japanese patentapplication publications No. 10-320229, No. 2000-267881, No. 2001-51025,No. 2001-134457, and No. 2002-333469, as means for verifying testenvironment without using real things such as a DUT or a test apparatus.

The Japanese patent application publications No. 10-320229 discloses:each emulator unit for emulating function of each hardware unit of asemiconductor test apparatus; a device emulator for emulating functionof DUT; means for collecting data required for execution of a testprogram from each of the emulator units based on a test program; and anemulator including a device test emulator for generating a test signalin a device emulator based on the collected data, comparing resultsignals from the device emulator, and storing the result therein.

The Japanese patent application publication No.2000-267881 discloses asemiconductor simulating apparatus for accurately simulating voltage andcurrent which change depending on internal resistance of the DUT.

The Japanese patent application publications No.2001-51025 discloses aprogram debugging apparatus for a semiconductor test including: testeremulation means for emulating operation of the semiconductor testapparatus; hardware description language simulating means for simulatingthe DUT based on the hardware description language; and debugging meansfor debugging the program for the semiconductor test based on thesimulating result of the DUT.

The Japanese patent application publications No. 2001-134457 discloses aprogram debugging apparatus for a semiconductor test for composing datapoints corresponding to each pin at high speed when emulating operationof the semiconductor test apparatus.

The Japanese patent application publications No. 2002-333469 discloses aprogram debugging apparatus for a semiconductor test for verifyingprogram for the semiconductor test being composed for a semiconductordevice including an analogue output terminal.

SUMMARY OF THE INVENTION

It is premised that the emulators of the test apparatuses describedabove are used for the test apparatus having a proprietary architecturebasically developed by a test apparatus vendor. On the other hand, intest apparatuses in the future, a method for constructing the testapparatus by combining modules developed by various vendors, which isrealized by an open architecture, is expected. Therefore, It isdesirable to offer an emulator for appropriately emulating the testapparatus constructed by the various modules.

Therefore, it is an object of the present invention to provide a testemulator, a test module emulator, and a record medium storing programtherein which can solve the foregoing problem. The above and otherobjects can be achieved by combinations described in the independentclaims. The dependent claims define further advantageous and exemplarycombinations of the present invention.

Therefore, according to the first aspect of the present invention, thereis provided a test emulator for emulating a test apparatus including aplurality of test modules for supplying a test signal to devices undertest respectively. The test emulator includes: a plurality of testmodule emulation sections for emulating the plurality of test modulesgenerating the test signal based on different cycles; a controlemulation section for emulating a control apparatus for controlling thetest of the devices under test; a synchronous emulation section forgenerating test signal generating timings, at which each of theplurality of test module emulation sections is to generate the testsignal in simulation corresponding to cycle time of the test moduleemulation section, based on instructions from the control emulationsection; a timing alignment section for aligning the plurality of testsignal generating timings generated by the synchronous emulation sectionin order of time, and outputting them one by one; and a schedule sectionfor causing the test module emulation section corresponding to one ofthe test signal generating timings output by the timing alignmentsection to generate the test signal in simulation in the cycle timecorresponding to the test signal generating timing.

The test emulator may further include a device under test simulatingsection for simulating operation of a device under test based on thetest signal generated in simulation.

The synchronous emulation section may further generate interruptioncollection timings for collecting interruption to the control apparatusgenerated in simulation by each of the plurality of test moduleemulation sections during the generation of the test signal in the cycletime corresponding to the test signal generating timings, the timingalignment section may align the plurality of test signal generatingtimings and the plurality of interruption collection timings in order oftime, and outputs them one by one, and the schedule section may causethe test module emulation section corresponding to the interruptioncollection timing to notify the control emulation section of theinterruption generated in simulation in the cycle time at which the testmodule emulation section generates the test signal just before theinterruption collection timing, in case that the timing alignmentsection outputs one of the interruption collection timings.

Each of the plurality of test module emulation sections may generatechange timing of the test signal in the cycle time at the generation ofthe test signal in the cycle time corresponding to the test signalgenerating timing, and the test emulator may further include a DUTconnection section for acquiring the plurality of change timingsgenerated by the plurality of test module emulation sections, and forchanging the test signal in simulation one by one in order of time basedon the plurality of change timings.

The DUT connection section supplies the plurality of change timingsacquired from the plurality of test module emulation sections to thetiming alignment section, the timing alignment section may align theplurality of change timings, the plurality of test signal generatingtimings, and the plurality of interruption collection timings in orderof time, and outputs them one by one, and the schedule section may causethe DUT connection section to change the test signal in simulation atthe change timing, in case that the timing alignment section outputs oneof the change timings.

Each of the plurality of the test module emulation sections may notifythe synchronous emulation section of the cycle end timing at which thecycle time ends during the generation of the test signal in the cycletime corresponding to the test signal generating timing, and thesynchronous emulation section may generate the test signal generatingtimings at which the test module emulation section generates the testsignal in simulation corresponding to next cycle time based on the cycleend timing notified from each of the plurality of test module emulationsections.

The schedule section may cause the interruption generated in simulationby the test module emulation section corresponding to the test signalgenerating timing to be notified to the control emulation section duringthe generation of the test signal in the cycle time just before the testsignal generating timing, in case that the timing alignment sectionoutputs the test signal generating timing corresponding to the nextcycle time.

Each of the plurality of test module emulation sections may be realizedby operating test module emulation program corresponding to the testmodule emulation section by a computer, and the test module emulationprogram may include: a plurality of hardware emulation functions, beingprovided corresponding to a plurality of commands received by the testmodule from the control apparatus respectively, for emulating operationof the test module corresponding to the command; and a control functionused in order for the schedule section to cause the test emulator togenerate the test signal in the cycle time corresponding to the testsignal generating timing.

According to the second aspect of the present invention, there isprovided a record medium storing therein program for causing a computerto function as a test emulator for emulating test apparatuses includinga plurality of test modules for supplying test signal to devices undertest respectively. The program causes the computer to function as: aplurality of test module emulation sections for emulating the pluralityof test modules generating the test signal based on different cycles; acontrol emulation section for emulating a control apparatus forcontrolling the test of the devices under test; a synchronous emulationsection for generating test signal generating timings, at which each ofthe plurality of test module emulation sections is to generate the testsignal in simulation corresponding to cycle time of the test moduleemulation section, based on instructions from the control emulationsection; a timing alignment section for aligning the plurality of testsignal generating timings generated by the synchronous emulation sectionin order of time, and outputting them one by one; and a schedule sectionfor causing the test module emulation section corresponding to one ofthe test signal generating timings output by the timing alignmentsection to generate the test signal in simulation in the cycle timecorresponding to the test signal generating timing.

According to the third aspect of the present invention, there isprovided a test module emulator for emulating a test module among aplurality of test modules by a test emulator for emulating testapparatuses including the plurality of test modules for supplying testsignal to devices under test respectively based on a different cycle.The test emulator includes: a control emulation section for emulating acontrol apparatus for controlling the test of the devices under test; asynchronous emulation section for generating test signal generatingtimings, at which each of the plurality of test module emulationsections is to generate the test signal in simulation corresponding tocycle time of the test module emulation section, based on instructionsfrom the control emulation section; a timing alignment section foraligning the plurality of test signal generating timings generated bythe synchronous emulation section in order of time, and outputting themone by one; and a schedule section for causing the test module emulationsection corresponding to one of the test signal generating timingsoutput by the timing alignment section to generate the test signal insimulation in the cycle time corresponding to the test signal generatingtiming, and the test module emulator includes a pattern generatoremulation section for generating the test signal in simulation in thecycle time corresponding to one of the test signal generating timingsbased on instructions from the schedule section.

The test module emulator may further includes a test module interfaceemulation section for notifying a synchronous emulation section of cycleend timing at which the cycle corresponding to one of the test signalgenerating timings ends, and causing the synchronous emulation sectionto further generate the test signal generating timing at which the testmodule emulator is to generate the test signal in simulation for thenext time based on the cycle end timing.

According to the fourth aspect of the present invention, there isprovided a record medium storing therein program for causing a computerto function as a test module emulator for emulating a test module amonga plurality of test modules as for a test emulator for emulating testapparatuses including the plurality of test modules for supplying testsignal to devices under test respectively based on a different cycle.The test emulator includes: a control emulation section for emulating acontrol apparatus for controlling the test of the devices under test; asynchronous emulation section for generating test signal generatingtimings, at which each of the plurality of test module emulationsections is to generate the test signal in simulation corresponding tocycle time of the test module emulation section, based on instructionsfrom the control emulation section; a timing alignment section foraligning the plurality of test signal generating timings generated bythe synchronous emulation section in order of time, and outputting themone by one; and a schedule section for causing the test module emulationsection corresponding to one of the test signal generating timingsoutput by the timing alignment section to generate the test signal insimulation in the cycle time corresponding to the test signal generatingtiming, and the program causes the computer to function as a patterngenerator emulation section for generating the test signal in simulationin the cycle time corresponding to one of the test signal generatingtimings based on instructions from the schedule section.

According to the fifth aspect of the present invention, there isprovided a test apparatus including a test module for supplying a testsignal to a device under test. The test apparatus includes: a controlapparatus for controlling a test of the device under test; a test modulefor generating a test signal based on a cycle; and a test moduleemulation section for emulating the test module. The control apparatusinputs an instruction about which of a real test or a simulation test isto be selected for the test of the device under test, the controlapparatus supplies the test module with a test program for testing thedevice under test and causes the test module to test the device undertest when the instruction indicates that the real test of the deviceunder test is to be performed, and the control apparatus supplies thetest module emulation section with a test program for testing the deviceunder test and causes the test module emulation section to simulate thetest of the device under test when the instructions indicates that thesimulation test of the device under test is to be performed.

The control unit may execute communication software for performingcommunication processing between the control unit and the test module,and the communication software may decide whether the test program is tobe supplied to the test module or the test module emulation sectionbased on the instructions included in calling for initializing thecommunication software in cooperation with the control apparatus.

According to the sixth aspect of the present invention, there isprovided a test emulator for emulating a test apparatus including aplurality of test modules for supplying a test signal to devices undertest. The test emulator includes: a plurality of test module emulationsections for emulating the plurality of test modules generating the testsignal based on a cycle; a control emulation section for emulating acontrol apparatus for controlling the test of the devices under test;and a schedule section for scheduling test signal generating timing atwhich each of the plurality of test module emulation sections is togenerate test signal corresponding to a cycle time in simulation. Thetest module emulation section outputs variation of voltage of the testsignal during the cycle time corresponding to the test signal generatingtiming by calling voltage setting method of an output channel objectwhich emulates an output channel for multiple times on receiving thetest signal generating timing by a function call, and the test moduleemulation section notifies that output of the variation of the voltageof the test signal corresponding to the cycle time is finished bycalling an end method of the output channel object output after theoutput of the variation of the voltage of the test signal correspondingto the cycle time is finished.

The schedule section may calculate a period during which all of the testmodule emulation sections finishes the output of the variation of thevoltage of the test signal based on the end method notified from each ofthe plurality of test module emulation sections, and the test emulatormay further comprise a device under test simulating section foracquiring the test signal within the period and simulates operation ofthe device under test during the period based on the test signal.

The output channel object may forbid the variation of the voltage in theperiod during which the output of the variation of the voltage of thetest signal was finished, which was notified by the end method, afterthe end method was called.

The summary of the invention does not necessarily describe all necessaryfeatures of the present invention. The present invention may also be asub-combination of the features described above.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing a configuration of a test apparatus 10according to an embodiment of the present invention.

FIG. 2 is a block diagram showing a functional configuration of a testemulator 190 according to an embodiment of the present invention.

FIG. 3 is a block diagram exemplary showing a hardware configuration ofa computer 20 according to an embodiment of the present invention.

FIG. 4 is a block diagram showing a functional configuration of a testmodule emulation section 270 according to an embodiment of the presentinvention.

FIG. 5 shows an example of a class hierarchical structure 500 accordingto an embodiment of the present invention.

FIG. 6 is a flow chart showing a test signal generating processing flowof the test emulator 190 according to an embodiment of the presentinvention.

FIG. 7 is a drawing exemplary showing the test signal simulated by thetest emulator 190 according to an embodiment of the present invention.

FIG. 8 illustrates software architecture according to an embodiment ofthe present invention.

FIG. 9 illustrates the use of test classes according to an embodiment ofthe invention.

FIG. 10 is a Unified Modelling Language (UML) diagram illustrating theinteraction of a tester system and different vendor-supplied moduleresources according to an embodiment of the invention.

FIG. 11 illustrates an embodiment of site controller objects formanaging a user's test as maintained by a site controller.

FIG. 12 illustrates an embodiment of an object surrogate at the systemcontroller side that represents the site controller object shown in FIG.11.

FIG. 13 illustrates a test environment according to an embodiment of theinvention.

FIG. 14 illustrates an example of a simulation configuration fileaccording to an embodiment of the present invention.

FIG. 15 illustrates another example of the simulation configuration fileaccording to an embodiment of the present invention.

FIG. 16 illustrates an example of an offline configuration fileaccording to an embodiment of the present invention.

FIG. 17 illustrates another example of the offline configuration fileaccording to an embodiment of the present invention.

FIG. 18 illustrates an example of a class hierarchical structure 5200according to an embodiment of the present invention.

FIG. 19 illustrates a specification diagram of a channel objectaccording to an embodiment of the present invention.

FIG. 20 illustrates a specification diagram of an event object accordingto an embodiment of the present invention.

FIG. 21 illustrates an example of a base class of the digital moduleaccording to an embodiment of the present invention.

FIG. 22 illustrates an example of class declaration of the digitaldriver module according to an embodiment of the present invention.

FIG. 23 illustrates an example of a handleEvent method of the digitaldriver module according to an embodiment of the present invention.

FIG. 24 illustrates class declaration of the digital strobe moduleaccording to an embodiment of the present invention.

FIG. 25 illustrates an example of a handleEvent method of the digitalstrobe module according to an embodiment of the present invention.

FIG. 26 illustrates an example of a class definition of a DUT modelaccording to an embodiment of the present invention.

FIG. 27 illustrates an example of a run method of the DUT modelaccording to an embodiment of the present invention.

FIGS. 28A and 28B illustrate positioning of a system bus access library6014 in real environment 6000 and emulation environment 6050.

DETAILED DESCRIPTION OF THE INVENTION

The invention will now be described based on the preferred embodiments,which do not intend to limit the scope of the present invention, butexemplify the invention. All of the features and the combinationsthereof described in the embodiment are not necessarily essential to theinvention.

FIG. 1 is a block diagram showing a configuration of a test apparatus 10according to an embodiment of the present invention. The test apparatus10 generates a test signal, supplies it to a DUT 100 (Device UnderTest), and judges acceptability of the DUT 100 based on whether a resultsignal, which is output from the DUT 100 as a result of the DUT 100being operated based on the test signal, coincides with an expectedvalue. The test apparatus 10 according to the present embodiment isrealized by an open architecture, and various kinds of modules based onthe open architecture are used as a test module 170 and the like forsupplying the test signal to the DUT 100. Moreover, the test apparatus10 includes a test emulator 190 for emulating a real test of the DUT1000, and the test emulator 190 provides an emulation environment forappropriately changing a configuration in response to the change of thetest module 170 and the like used for the real test, and forappropriately emulating the real test of the DUT 1000.

The test apparatus 10 includes a system controller 110, atelecommunication network 120, site controllers 130 a-130 c, a busswitch 140, synchronous modules 150 a-150 b, synchronous connectionmodules 160 a-160 b, the test modules 170 a-170 b, a load board 180, andthe test emulator 190. The test apparatus 10 connects with the DUTs 100a-100 b.

The system controller 110 receives and stores test control program, testprogram, test data and the like, which is used for the test of the DUTs100 a-100 b by the test apparatus 10, through an external network or thelike. The telecommunication network 120 connects the system controller110, the site controllers 130 a-130 c, and the test emulator 190, andrelays communication between them.

The site controllers 130 a-130 c are examples of the control apparatusaccording to the present invention, and control the test of the DUTs100. Here, each of the plurality of site controllers 130 controls thetest of one of the DUTs 100 respectively. For example, in FIG. 1, thesite controller 130 a controls the test of the DUT 100 a, and the sitecontroller 130 b controls the test of the DUT 100 b. Alternatively, theplurality of site controllers 130 control the test of the plurality ofDUTs 100 respectively.

More specifically, the site controller 130 acquires the test controlprogram from the system controller 110 through the telecommunicationnetwork 120 and executes it. Next, based on the test control program,the site controller 130 acquires the test program and the test data usedfor the test of the DUT 100 from the system controller 110, and storesthem in a module, such as the synchronous modules 150 or one or aplurality of the test module 170, which is used for the test of the DUT100, through the bus switch 140. Next, the site controller 130 instructsthe start of the test to the synchronous module 150 through the busswitch 140 based on the test program and the test data. Then, the sitecontroller 130 receives an interruption, which indicates that the testis completed, from, for example, the synchronous module 150, and causeseach of the modules to perform the next test based on the test result.

The bus switch 140 connects each of the plurality of site controllers130 to the synchronous modules 150 and one or a plurality of the testmodules 170 which are controlled by the site controller 130, and relaysthe communication between them. Here, a predetermined site controller130 sets up the bus switch 140 in order to connect each of the pluralityof site controllers 130 with the synchronous module 150 and one or aplurality of the test modules 170 used by the site controller 130 forthe test of the DUT 100, based on the instruction of a user of the testapparatus 10, the test control program, etc. For example, in FIG. 1, thesite controller 130 a is set up so that it connects with the synchronousmodule 150 a and the plurality of test modules 170 a, thereby the DUT100 a is tested. Moreover, the site controller 130 b is set up so thatit connects with the synchronous module 150 b and the plurality of testmodules 170 b, thereby the DUT 100 b is tested.

Here, since configuration and operation of the site controller 130 b fortesting the DUT 100 b using the synchronous module 150 b, thesynchronous connection modules 160 b and one or a plurality of the testmodule 170 b are substantially the same as configuration and operationof the site controller 130 a for testing the DUT 100 a using thesynchronous module 150 a, the synchronous connection modules 160 a andone or a plurality of the test module 170 a, the configuration and theoperation of the site controller 130 a for testing the DUT 100 a will bemainly described hereinafter unless there is no difference.

The synchronous module 150 a generates a test signal generating timing,at which the plurality of test modules 170 used for the test of the DUT100 a are to generate the test signal, based on the instruction of thesite controller 130 a. Moreover, the synchronous module 150 a receivesthe test result from one or a plurality of the test modules 170 athrough the synchronous connection module 160 a, and causes one or aplurality of the test module 170 a to perform sequence of the testprogram according to the acceptability of the test result.

The synchronous connection module 160 a notifies the test module 170 aof the test signal generating timing generated by the synchronous module150 a, where the test module 170 a is to be operated corresponding tothe test signal generating timing. Then, the synchronous connectionmodule 160 a causes each of one or a plurality of the test modules 170 ato operate at a predetermined timing. Moreover, the synchronousconnection module 160 a receives the test result from one or a pluralityof the test modules 170 a, and transmits it to the synchronous module150 a.

The plurality of test modules 170 a connect with a part of a pluralityof terminals of the 100 a respectively, and tests the DUT 100 a based onthe test program and the test data stored in the site controller 130 a.During the test of the DUT 100 a, test module 170 a generates the testsignal from the test data based on the sequence defined by the testprogram, and supplies the test signal to the terminals of the DUT 100 aconnected to the test modules 170 a. Next, test module 170 a acquiresthe result signal, which is output as a result of the DUT 100 a beingoperated based on the test signal, and the result signal is comparedwith an expected value. Then, the test module 170 a transmits thecomparison result of the result signal and the expected value to thesynchronous connection module 160 a as the test result. Here, theplurality of test modules 170 a generate the test signal based ondifferent cycles in order to change the cycle of the test signaldynamically based on the test program and the test data.

Moreover, the test module 170 a generates an interruption to the sitecontroller 130 a, when the processing of the test program is completed,or when an abnormality occurs during the execution of the test program.This interruption is notified to the site controller 130 a correspondingto the test module 170 a through the bus switch 140, and interruptionprocessing is performed by the processor of the site controller 130 a.

The plurality of DUTs 100 are mounted on the load board 180, by whichthe plurality of test modules 170 and the corresponding terminals of theDUTs 100 are connected.

The test emulator 190 emulates the test apparatus 10 based on the testcontrol program, the test program, and the test data stored in thesystem controller 110. Then, the test emulator 190 simulates the test ofthe DUT 100 using the simulation model of the DUT 100. In the presentembodiment, the test emulator 190 simulates the operation of the sitecontroller 130, the synchronous module 150 and the synchronousconnection modules 160 and one or a plurality of the test modules 170controlled by the site controller 130, and the DUT 100 which is to betested by the corresponding site controller 130. By using the testemulator 190, the user of the test apparatus 10 starts the verificationof the test control program, the test program, and/or the test dataprior to the preparation of the DUT 100, the synchronous module 150, thesynchronous connection module 160, the test module 170, etc. Moreover,by providing the plurality of test emulators 190, the test controlprogram, the test program, and/or the test data are developed, withouteach of the plurality of users occupying the expensive real testenvironment.

As stated above, the test apparatus 10 is realized by an openarchitecture and various kinds of modules, which fulfil thespecification of the open architecture, are utilized. Then, the testapparatus 10 is used by inserting the modules, such as the synchronousmodule 150, the synchronous connection module 160, and the test module170, into arbitrary connection slots of the bus switch 140. At thistime, the user of the test apparatus 10 etc. changes topology of the busswitch 140 through the site controller 130 a for example, causes theplurality of modules used for the test of the DUT 100 to connect withthe site controller 130 for controlling the test of the DUT 100.Thereby, the user of the test apparatus 10 selects a suitable moduleaccording to the number of the terminals, the arrangement of theterminals, the kind of the terminals, or the kind of the test for eachof the plurality of the DUTs 100, and mounts the module on the testapparatus 10.

Alternatively, as a substitution for the above-mentioned example, thesynchronous connection module 160 a and the synchronous connectionmodule 160 b are realized by a synchronous connection section providedfor all of the test modules 170 used for the test apparatus 10. In thiscase, the user of the test apparatus 10 etc. selects a suitable moduleaccording to the property of the plurality of DUTs 100 by changing thetopology of the synchronous connection section and the test module 170with the change of the topology of the bus switch 140.

FIG. 2 is a block diagram showing a functional configuration of the testemulator 190 according to the embodiment of the present invention. Thetest emulator 190 includes a site control emulation section 230, a busswitch emulation section 240, a synchronous module emulation section250, a synchronous connection module emulation section 260, one or aplurality of test module emulation sections 270, a DUT connectionsection 280, a DUT simulating section 200, and a schedule controlsection 275. Hereinafter, a case where the test emulator 190 emulatesthe test of the DUT 100 a by the site controller 130 a will beexplained.

The site control emulation section 230 emulates the site controller 130a illustrated in FIG. 1. That is, the site control emulation section 230acquires the test control program from the system controller 110 throughthe telecommunication network 120 and executes it. Next, the sitecontrol emulation section 230 acquires the test program and the testdata, which are used for the test of the DUT 100 a based on the testcontrol program, from the system controller 110, and stores them inmodule emulation sections such as the synchronous module emulationsection 250 or one or a plurality of the test module emulation sections270 through the bus switch emulation section 240.

Here, the site control emulation section 230 issues simulation commands,such as read-out access and write-in access from/to a storage area inthe module, to the bus switch emulation section 240, where real commandsare to be issued by the site controller 130 a to the synchronous modules150 a and one or a plurality of the test modules 170 a. The site controlemulation section 230 stores the test program and the test data in thesynchronous module emulation sections 250, one or a plurality of thetest module emulation sections 270, etc. through the bus switchemulation section 240 by issuing the write-in access of the test programand the test data in simulation to the bus switch emulation section 240.

Moreover, the site control emulation section 230 receives theinterruption simulated by the synchronous module emulation section 250and the test module emulation section 270 through the bus switchemulation section 240, and simulates the interruption processing of thesite controller 130 a.

The bus switch emulation section 240 emulates the bus switch 140illustrated in FIG. 1, and relays the communication between the sitecontrol emulation section 230, and the synchronous module emulationsections 250 and one or a plurality of the test module emulationsections 270.

The synchronous module emulation section 250 emulates the synchronousmodule 150 illustrated in FIG. 1, and generates the test signalgenerating timing, at which each of the plurality of test moduleemulation sections 270 is to generate the test signal in simulationcorresponding to the cycle time of the test module emulation section270, based on the instructions from the site control emulation section230. Next, the synchronous module emulation section 250 receives cycleend timing, which is the end timing of the cycle time, from the testmodule emulation section 270 which generates the test signal. Then,according to the cycle end timing, the synchronous module emulationsection 250 generates: a test signal generating timing at which the testmodule emulation section 270 is to generate the next test signal; a testresult collection timing for collecting the test results from the testmodule emulation section 270; a cycle termination timing for causing thetest module emulation section 270 to terminate the processing of thecycle time; and an interruption collection timing for collecting theinterruption to the site control emulation section 230 from the testmodule emulation section 270. Here, the interruption to the site controlemulation section 230 from the test module emulation section 270 is thesimulated interruption generated by each of the plurality of test moduleemulation sections 270 for the site controller 130 a during thegeneration of the test signal in the cycle time corresponding to thetest signal generating timing.

The synchronous connection module emulation section 260 emulates thesynchronous connection module 160 illustrated in FIG. 1, and notifiesthe schedule control section 275 of the test signal generating timinggenerated by the synchronous module emulation section 250 in simulation,the test result collection timing and the cycle termination timing andthe interruption collection timing which are generated by thesynchronous module emulation section 250 for the emulation. Moreover,the synchronous connection module emulation section 260 receives thetest result from one or a plurality of the test module emulationsections 270, and transmits it to the synchronous module emulationsection 250.

The test module emulation section 270 receives instruction of a cyclestart from the synchronous module emulation section 250 which receivedinstructions of a test signal generation, and generates the test signalin simulation in the cycle time corresponding to the test signalgenerating timing based on the test program and the test data stored inthe site control emulation section 230. More specifically, the testmodule emulation section 270 generates a change timing of the testsignal in simulation in the cycle time during the generation of the testsignal in the cycle time corresponding to the test signal generatingtiming. Alternatively, the test module emulation section 270 generateschange timings corresponding to a cycle time as a change timing of thetest signal, where the number of the change timings is defined byspecification of the test module 170 corresponding to the test moduleemulation section 270. Moreover, the test module emulation section 270acquires the output signal output as a result of the DUT simulatingsection 200 being operated in simulation based on the test signal, andcompares the result with the expected value defined based on the testprogram and the test data. Then, the test module emulation section 270transmits the comparison result of the result signal and the expectedvalue to the synchronous module emulation section 250 through thesynchronous connection module emulation section 260 as the test result.

Moreover, in response to instruction of the interruption from theschedule section 277, the test module emulation section 270 notifies thesite control emulation section 230 through the bus switch emulationsection 240 of the interruption generated in simulation in the cycletime during which the last test signal before receiving the instructionof the interruption is generated.

The DUT connection section 280 acquires the plurality of change timingsgenerated by the plurality of test module emulation sections 270, andchanges the test signal in simulation in order of time based on theplurality of change timings.

The DUT simulating section 200 simulates operation of the DUT 100described by hardware description languages, such as Verilog-HDL orVHDL, based on the test signal acquired from the DUT connection section280. Then, the DUT simulating section 200 generates a result signal bythe simulation, which is output as a result of the DUT 100 beingoperated based on the test signal, and supply it to the test moduleemulation section 270 through the DUT connection section 280.

The schedule control section 275 controls the schedule which operateseach of the module emulation sections based on various kinds of timingsgenerated by the plurality of module emulation sections in the simulatedtest of the DUT 100 by the synchronous module emulation section 250, thesynchronous connection module emulation section 260, the plurality oftest module emulation sections 270, and the DUT connection section 280.The schedule control section 275 includes a timing alignment section 276and a schedule section 277.

The timing alignment section 276 aligns the plurality of test signalgenerating timings, the plurality of interruption collection timings,the plurality of cycle termination timings and the plurality of testresult collection timings, which are generated by the synchronous moduleemulation section 250, and the plurality of change timings that aregenerated by one or a plurality of the test module emulation sections270 and are supplied by the DUT connection section 280, in order oftime. Then, the timing alignment section 276 outputs these alignedtimings to the schedule section 277 one by one. The schedule section 277notifies the module emulation section and the DUT connection section 280corresponding to the timings of each of the timings output from thetiming alignment section 276 one by one. Then, the schedule section 277causes the module emulation section or the DUT connection section 280 toperform the operation corresponding to the timings. The operation of theschedule section 277 according to the kind of the timing output from thetiming alignment section 276 will be explained hereinafter.

(1) In case that the timing alignment section 276 outputs test signalgenerating timing

The schedule section 277 notifies the synchronous module emulationsection 250 of the test signal generating timing, and instructs thegeneration of the test signal by the test module emulation section 270corresponding to the test signal generating timing through thesynchronous module emulation section 250. Thereby, the schedule section277 causes the test module emulation section 270 corresponding to thetest signal generating timing to generate the test signal in simulationin the cycle time corresponding to the test signal generating timingthrough the synchronous module emulation section 250.

(2) In case that the timing alignment section 276 outputs theinterruption collection timing

The schedule section 277 instructs the generation of the interruption tothe test module emulation section 270 which is designated correspondingto the interruption collection timing. Thereby, the schedule section 277causes the test module emulation section 270 to notify the site controlemulation section 230 through the bus switch emulation section 240 ofthe interruption generated in simulation in the cycle time during whichthe test signal is generated just before the interruption collectiontiming.

(3) In case that the timing alignment section 276 outputs the cycletermination timing

The schedule section 277 notifies the test module emulation section 270corresponding to the cycle termination timing that the cycle end timinghas come.

(4) In case that the timing alignment section 276 outputs the testresult collection timing

The schedule section 277 notifies the test module emulation section 270corresponding to the test result collection timing that the test resultcollection timing has come. In response, the test module emulationsection 270 notifies the synchronous module emulation section 250through the synchronous connection module emulation section 260 of thecomparison result of the result signal and the expected value in thecycle time.

(5) In case that the timing alignment section 276 outputs the changetiming

The DUT connection section 280 supplies the plurality of change timingacquired from the plurality of test module emulation sections 270 to thetiming alignment section 276. In response, the timing alignment section276 aligns the plurality of change timings and other various timingsaltogether in order of time.

If the timing alignment section 276 outputs the change timing, theschedule section 277 notifies the DUT connection section 280 that thechange timing has come, in order to change the test signal in simulationat the change timing. In response, the DUT connection section 280changes the test signal in simulation at the change timing.

Here, the test module emulation section 270 notifies the schedulecontrol section 275 of result signal acquisition timing, which is atiming of the acquisition of the result signal. Then, the timingalignment section 276 aligns the result signal acquisition timing andthe other various timings in order of time. In this case, when thetiming alignment section 276 outputs the result signal acquisitiontiming, the schedule section 277 causes the DUT connection section 280to supply the result signal to the test module emulation section 270which is to acquire the result signal at the result signal acquisitiontiming.

Moreover, the DUT connection section 280 acquires the plurality ofchange timings generated by the plurality of test module emulationsections 270, and supplies them to the DUT simulating section 200,without aligning them in order of time. In this case, the DUT simulatingsection 200 aligns the plurality of supplied change timings in order oftime, and performs the simulation of the DUT 100 based on a plurality ofaligned change timings.

According to the test emulator 190 described above, by providing thesynchronous module emulation section 250, the synchronous connectionmodule emulation section 260 and one or a plurality of the test moduleemulation sections 270 respectively corresponding to the synchronousmodule 150, the synchronous connection modules 160 and one or aplurality of the test modules 170 of the real system of the testapparatus 10, the module emulation sections can be easily replaced asother module emulation sections. Thereby, in case that one module isreplaced as another modules in the real system of the test apparatus 10,in the test emulator 190, a module emulation section corresponding tothe module is replaced by a module emulation section corresponding tothe other module. Then substantially the same test environment as thereal system of the test apparatus 10 is provided on the test emulator190.

Alternatively, as a substitution for the above-mentioned example, thesite control emulation section 230, the bus switch emulation section240, the synchronous module emulation section 250, the test moduleemulation section 270, the schedule control section 275, the DUTconnection section 280, and the DUT simulating section 200 are realizedby a distributed system including a plurality of computers.

FIG. 3 is a block diagram exemplary showing a hardware configuration ofthe test emulator 190 according to the present embodiment of theinvention. The test emulator 190 according to the present embodiment isrealized by a computer 20 which includes CPU 300, ROM 310, RAM 320, acommunication interface 330, a hard disk drive 340, a flexible diskdrive 350, and a CD-ROM drive 360.

The CPU 300 operates based on the program stored in the ROM 310 and theRAM 320, and controls each part. The ROM 310 stores boot program whichthe CPU 300 executes during start up of a computer 20, program dependingon the hardware of the computer 20 and the like. The RAM 320 storesprogram which the CPU 300 executes, data which the CPU 300 uses. Thecommunication interface 330 communicates with other equipments through atelecommunication network. The hard disk drive 340 stores the programand the data which the computer 20 uses, and supplies them to the CPU300 through the RAM 320. The flexible disk drive 350 reads program ordata in a flexible disk 390, and provides them to the RAM 320. TheCD-ROM drive 360 reads program or data in a CD-ROM 395, and providesthem to the RAM 320.

The program provided to the CPU 300 through the RAM 320 is stored in arecord medium, such as the flexible disk 390, the CD-ROM 395, or an ICcard, which is provided by a user. The program is read from the recordmedium, installed in the computer 20 through the RAM 320, and executedby the computer 20.

The program modules, which are installed and executed in/by the computer20 and causes the computer 20 to function as the test emulator 190,includes a DUT simulating module, a site control emulation module, a busswitch emulation module, a synchronous module emulation module, asynchronous connection module emulation module, a test module emulationmodule, a schedule control module, a timing alignment module, a schedulemodule, and a DUT connection module. The programs or the modules causesthe computer 20 to function as the DUT simulating section 200, the sitecontrol emulation section 230, the bus switch emulation section 240, thesynchronous module emulation section 250, the synchronous connectionmodule emulation section 260, the test module emulation section 270, theschedule control section 275, the timing alignment section 276, theschedule section 277, and the DUT connection section 280 respectively.

Alternatively, the programs or the modules described above are stored inan external record medium. It is possible to use an optical recordmedium such as DVD or PD, a magneto-optical record medium such asMinidisk, a tape medium, a magnetic record medium or a semiconductormemory such as an IC card as a record medium instead of the flexibledisk 390 and the CD-ROM 395. Moreover, a storage device, such as a harddisk or RAM in a server system on a dedicated telecommunication networkor the Internet, is used as a record medium and the program may beprovided to the computer 20 via the telecommunication network.

FIG. 4 is a block diagram showing a functional configuration of the testmodule emulation section 270 according to the embodiment of the presentinvention. In FIG. 4, the test module emulation section 270 is realizedby operating the test module emulation program or test module emulationmodule corresponding to the test module emulation section 270 by thecomputer 20.

The test module emulation section 270 includes a plurality of hardwareemulation functions provided corresponding to each of the plurality ofcommands received by the test module 170 through the bus switch 140 fromthe site controller 130, and a control function called in order tonotify the test module emulation section 270 of various kinds oftimings. The test module emulation section 270 operates in response tothe call to these functions from the bus switch emulation section 240and the schedule control section 275. Here, the control function is usedin order for the schedule control section 275 to order the generation ofthe test signal in simulation in the cycle time corresponding to thetest signal generating timing, and to order to notify the site controlemulation section 230 of the interruption generated in simulation in thecycle time when the test module emulation section 270 generates the testsignal just before the interruption collection timing.

The test module emulation section 270 includes a test module IFemulation section 400 (test module interface emulation section), apattern generator emulation section 430, a waveform shaper emulationsection 440, a pin control emulation section 450, and a parametermeasurement emulation section 460.

The test module IF emulation section 400 is started-up when the hardwareemulation function is called from the bus switch emulation section 240,and when the control function is called from the schedule controlsection 275. The test module IF emulation section 400 controls theoperation of the test module emulation section 270 corresponding tothese function calling. The test module IF emulation section 400includes a machine word DB 420 and a control function processing section410.

The machine word DB 420 emulates a storage area stored in the storagearea provided in the test module 170. When the machine word DB 420receives a command from the site control emulation section 230 insimulation through the bus switch emulation section 240 by the callingof the hardware emulation function, it accesses the storage area in themachine word DB 420 corresponding to the command.

More specifically, the test module IF emulation section 400 according tothe present embodiment stores a plurality of hardware emulationfunctions for emulating the operation of the test module emulationsection 270 corresponding to a plurality of commands, such as read-outaccess and write-in access, respectively. When the read-out access isreceived from the site control emulation section 230 through the busswitch emulation section 240, the test module IF emulation section 400replies the data in the machine word DB 420 corresponding to the storagearea for the read-out access, to the site control emulation section 230through the bus switch emulation section 240. Moreover, when the machineword DB 420 receives the write-in access, it stores the data to bewritten in the storage area of the machine word DB 420 corresponding tothe storage area for the write-in access. For example, when the machineword DB 420 receives the write-in access of the test program or the testdata from the site control emulation section 230 through the bus switchemulation section 240, it stores the test programs or the test data inthe storage area of the machine word DB 420 corresponding to thewrite-in access.

When the control function processing section 410 receives the controlfunction call from the schedule control section 275, the controlfunction processing section 410 causes the pattern generator emulationsection 430, the waveform shaper emulation section 440, the pin controlemulation section 450, and the parameter measurement emulation section460 to emulate the operation of the test module 170 according to thecontrol function in response to the instruction of the control function.More specifically, when the schedule control section 275 instructs thegeneration of the test signal using the control function in the cycletime corresponding to the test signal generating timing, the controlfunction processing section 410 reads a part of the program and a partof the data among the test program and the test data stored in themachine word DB 420, where the part of the program and the data are tobe processed by the test module emulation section 270 during the cycletime. Then, the control function processing section 410 causes thepattern generator emulation section 430, the waveform shaper emulationsection 440, the pin control emulation section 450, and the parametermeasurement emulation section 460 to perform the processingcorresponding to the part of the program and the part of the data.

The pattern generator emulation section 430 emulates the patterngenerator of the test module 170. That is, the pattern generatoremulation section 430 receives the test program and the test data storedin the machine word DB 420 from the control function processing section410 by the function call, for example. Then the instruction, whichindicates that the test signal is to be generated for a certain cycletime, is received from the schedule control section 275 by the functioncall through the control function processing section 410, and the testsignal, which is to be generated in the cycle time, is generated insimulation.

Moreover, the pattern generator emulation section 430 acquires theresult signal through the DUT connection section 280 and the waveformshaper emulation section 440, which is output in simulation as a resultof the DUT simulating section 200 being operated based on the testsignal, and the result signal is compared with the expected value.

The waveform shaper emulation section 440 emulates the waveform shaperof the test module 170. That is, the waveform shaper emulation section440 shapes the waveform of the test signal in simulation in response tothe test signal from the pattern generator emulation section 430. Thenthe waveform is output to the DUT connection section 280.

The pin control emulation section 450 emulates the pin control sectionof the test module 170. That is, the pin control emulation section 450sets parameters, such as operating voltage, for each terminal from whichthe test signal is output in simulation by the waveform shaper emulationsection 440 and/or the parameter measurement emulation section 460 basedon the test program.

The parameter measurement emulation section 460 emulates the parametermeasurement section of the test module 170. That is, for example, theparameter measurement emulation section 460 receives an instruction of adirect current test (DC parametric test) from the schedule controlsection 275 through the control function processing section 410 by thefunction call, and generates the test signal in simulation, which is tobe generated in the cycle time of the direct current test. Moreover, theparameter measurement emulation section 460 acquires the result signal,which is output in simulation as a result of the DUT simulating section200 being operated based on the test signal in the direct current test.

Moreover, in case that the test module emulation section 270 generatesthe test signal in the cycle time corresponding to the test signalgenerating timing, the control function processing section 410 notifiesthe synchronous module emulation section 250 of the cycle end timing atwhich the cycle, which corresponds to the test signal generating timing,ends.

As stated above, the control function processing section 410 notifiesthe synchronous module emulation section 250 through the schedulecontrol section 275 of the cycle end timing at which the cycle ends inthe generation of the test signal in the cycle time corresponding to thetest signal generating timing. Thereby, the control function processingsection 410 causes the synchronous module emulation section 250 tofurther generate the test signal generating timing at which the testmodule emulation section 270 is to generate the test signal insimulation for the next time based on the cycle end timing.

Moreover, when the control function processing section 410 receives theinstruction of the interruption generation from the schedule controlsection 275, the control function processing section 410 transmits theinstruction of the interruption generation to the pattern generatoremulation section 430, the waveform shaper emulation section 440, andthe pin control emulation section 450 by the function call, for example.The pattern generator emulation section 430, the waveform shaperemulation section 440, and the pin control emulation section 450, whichreceive the instruction of the interruption generation, notify thecontrol function processing section 410 of the interruption generated insimulation in the cycle time just before the interruption collectiontiming among the cycle times during which the test module emulationsection 270 generates the test signal. When the interruption isnotified, the control function processing section 410 notifies the sitecontrol emulation section 230 of the interruption through the bus switchemulation section 240 by calling the hardware emulation function for thenotification of the interruption included in the bus switch emulationsection 240, for example.

FIG. 5 shows an example of a class hierarchical structure 500 accordingto the embodiment of the present invention. In the present embodiment,module emulation program, which realizes the module emulation sectionssuch as the synchronous module emulation section 250, the synchronousconnection module emulation section 260, and the test module emulationsection 270, is created using class functions, which are frameworks ofthe module emulation program defined in order to realize the openarchitecture of the test apparatus 10 in simulation.

The simulation component class 510 is a class which defines rules forcalling a plurality of parameters, return values and etc. of methodfunctions, which are to be included in the module emulation program,with a virtual method function. The simulation component class 510includes a plurality of virtual hardware emulation functions 512 and aplurality of virtual control functions 514.

Here, read( ) is a method function for emulating the operation of themodule corresponding to the read-out access which is called when thesite control emulation section 230 issues the read-out access command insimulation. write ( ) is a method function for emulating operation ofthe module corresponding to the write-in access which is called when thesite control emulation section 230 issues the write-in access command insimulation. setBaseAddress( ) is a method function which is called whenthe site control emulation section 230 issues in simulation the baseaddress setting command, which is issued by the site controller 130 whenthe base address of the storage area of the test module 170 is set up.

registerEvent( ) is a method function which is called when thesynchronous connection module emulation section 260, the test moduleemulation section 270, and the DUT connection section 280, which receivethe notices from the synchronous module emulation section 250, notifythe timing alignment section 276 of the interruption collection timing,the change timing, the result signal acquisition timing, etc. andregister the timings to the timing alignment section 276. handleEvent( )is a method function which is called by the schedule control section275, in order to cause the synchronous module emulation section 250, thesynchronous connection module emulation section 260, the test moduleemulation section 270, and the DUT connection section 280 to perform theprocessing in response to the timings when the test signal generatingtiming, the interruption collection timing, the change timing, theresult signal acquisition timing, etc. have come. raiseEvent( ) is amethod function which is called when the synchronous module emulationsection 250, the synchronous connection module emulation section 260,the test module emulation section 270, and the DUT connection section280 notify the schedule control section 275 of an event which is to beprocessed asynchronously without regard to the timings.

A Company A's module class 520 and a Company B's module class 530 areclasses derived from the simulation component class 510, i.e., moduleemulation programs, which are supplied by manufacturers of the modulesfor example, for emulating common function included in the modules ofthe manufacturers in common. The Company A's module class 520 and theCompany B's module class 530 include a plurality of real hardwareemulation functions 522 and a plurality of real control functions 524respectively. Each of the plurality of real hardware emulation functions522 and the plurality of real control functions 524 are module emulationprograms which are described corresponding to the plurality of virtualhardware emulation functions 512 and the plurality of virtual controlfunctions 514 respectively, and describe the contents of the processingof the real method functions (non-virtual method functions)corresponding to the virtual method functions.

The Company A's module class 520 and the Company B's module class 530include classes which are further derived. For example, in FIG. 5, theCompany B's module class 530 is further derived in a digital test moduleclass 540, a power source module class 560, and a synchronous moduleclass 590.

The digital test module class 540 is a class of test module emulationprogram for emulating the test module 170 for performing the functionaltest of the DUT 100. The digital test module class 540 is furtherderived in a 250 MHz digital test module class 550 for emulating thetest module 170 which performs the functional test of the DUT 100 at afrequency of 250 MHz. The power source module class 560 is a class ofmodule emulation program for emulating the module for supplying electricpower to the DUT 100. The power source module class 560 is furtherderived in a high voltage power source module class 570 for emulatingthe module which supplies high voltage power to the DUT 100, and the lowvoltage power source module class 580 for emulating the module whichsupplies low voltage power to the DUT 100. The synchronous module class590 is a class of module emulation program for emulating the synchronousmodule 150.

Each of the 250 MHz digital test module class 550, the high voltagepower source module class 570, the low voltage power source module class580, and the synchronous module class 590 includes real method functionhandleEvent( ) for emulating the original function of each of themodules, which is used by replacing (overriding) the handleEvent( ) inthe Company B's module class 530.

Each of the synchronous module emulation section 250, the synchronousconnection module emulation section 260, one or a plurality of the testmodule emulation sections 270 etc. included in the test emulator 190 isrealized as one instance of the classes of the module emulation programsincluded in the class hierarchical structure 500.

As described above, each of the synchronous module emulation section250, the synchronous connection module emulation section 260, the moduleemulation section of test module emulation section 270 etc., which isincluded in the test emulator 190, is realized by the module emulationprogram corresponding to one of the classes included in the classhierarchical structure 500 for example. A user of the test emulator 190builds substantially the same test environment as the real system of thetest apparatus 10 in the test emulator 190 by generating the instance ofthe module emulation program from the combination of the classescorresponding to the combination of the modules which are to be mountedin the real system of the test apparatus 10. Moreover, in case ofcreating a new class corresponding to a new module, man-hour forcreating module emulation program is reduced by creating a new class asan inherited class of one of the existing classes.

FIG. 6 shows a test signal generating processing flow of the testemulator 190 according to the embodiment of the present invention, whichis proceeded by the test module emulation section 270.

When the site control emulation section 230 instructs the start of thetest to the synchronous module emulation section 250 where the testprogram and the test data are stored in the synchronous module emulationsection 250, the synchronous connection module emulation section 260 andone or a plurality of the test module emulation sections 270, the testemulator 190 proceeds the test in simulation according to a proceduredescribed below.

First, in case that the timing alignment section 276 outputs the testsignal generating timing, the schedule section 277 of the schedulecontrol section 275 (shown as SCHED in the figure) calls thehandleEvent( ) function of the synchronous module emulation section 250(shown as SYNC in the figure), and notifies that the test signalgenerating timing has come (S600). Thereby, the schedule control section275 causes the test module emulation section 270 corresponding to thetest signal generating timing to generate the test signal in simulationin the cycle time corresponding to the test signal generating timingthrough the synchronous module emulation section 250. Here, the schedulecontrol section 275 notifies the synchronous module emulation section250 of the test signal generating timing by including the eventidentifier, which identifies that the test signal generating timing ofthe corresponding test module emulation section 270 has come, in aparameter of the handleEvent( ) function.

Next, the synchronous module emulation section 250 notifies the testmodule emulation section 270 (shown as TM in the figure), which is togenerates the test signal in simulation in the test signal generatingtiming, of the cycle start which is the instructions for starting theprocessing of the cycle time and generating the test signal (S605).Here, the synchronous module emulation section 250 notifies the testmodule emulation section 270 of the cycle start through the schedulecontrol section 275 asynchronous to the timings which are aligned by thetiming alignment section 276 in order of time by including the eventidentifier, which instructs the cycle start, in the parameter of araiseEvent( ) function, and calling the schedule control section 275.

Next, the test module emulation section 270 generates the test signal insimulation in the corresponding cycle time in response to the notice ofthe cycle start (S610). That is, in S600, when the schedule controlsection 275 notifies the synchronous module emulation section 250 of thetest signal generating timing so as to generate the test signal insimulation in the cycle time corresponding to test signal generatingtiming, and when the synchronous module emulation section 250, whichreceives the notice, notifies the test module emulation section 270 ofthe cycle start through the schedule control section 275, the testmodule emulation section 270 generates the test signal in simulation inthe cycle time. Here, the test module emulation section 270 generatesthe change timing of the test signal in simulation in the cycle timeduring the generation of the test signal in the cycle time.

Next, the DUT connection section 280 (shown as LB in the figure)notifies the timing alignment section 276 of the change timing inresponse to the change timing of the test signal from the test moduleemulation section 270, and registers it (S615).

Next, the test module emulation section 270 notifies the synchronousmodule emulation section 250 of the timing for end of the cycle (S620).Here, the test module emulation section 270 generates the test signal bythe pattern generator emulation section 430 based on the designation bythe test program and the test data, changing each cycle timedynamically. For this reason, the control function processing section410 in the test module IF emulation section 400 of the test moduleemulation section 270 acquires the termination timing of each of thecycles from the pattern generator emulation section 430, and notifiesthe synchronous module emulation section 250 of the end timing, andcauses the synchronous module emulation section 250 to generate the nexttest signal generating timing accurately.

Next, based on the cycle end timing notified from the test moduleemulation section 270 in S620, the synchronous module emulation section250 generates the test signal generating timing at which the test moduleemulation section 270 is to generate the test signal in simulationcorresponding to the next cycle time, notifies the timing alignmentsection 276 of the timing and registers it (S625). Moreover, thesynchronous module emulation section 250 further generates a test resultcollection timing for collecting the test results from the test moduleemulation section 270, a cycle termination timing for terminating thecycle time of the test module emulation section 270, and theinterruption collection timing for collecting the interruption which isgenerated by the test module emulation section 270 in simulation duringthe generation of the test signal in the cycle time. Then thesynchronous module emulation section 250 notifies the timing alignmentsection 276 of the timings and registers them (S625). Here, thesynchronous module emulation section 250 registers the timings into thetiming alignment section 276 by calling the registerEvent( ) function inthe schedule control section 275.

In addition, the synchronous module emulation section 250 generatessubstantially the same timing as the cycle end timing received from thetest module emulation section 270 as the test signal generating timing,the test result collection timing, the cycle termination timing, and theinterruption collection timing for the next time in the test moduleemulation section 270.

Next, when the timing alignment section 276 outputs the change timingwhich is registered in S615, the schedule section 277 notifies the DUTconnection section 280 that the change timing has come so as to changethe test signal in simulation at the timing (S630).

Next, when the change timing is notified from the schedule section 277,the DUT connection section 280 generates the test signal by changing thetest signal in simulation at the change timing, and supplies it to theDUT simulating section 200 (S635). The DUT simulating section 200simulates the operation of the DUT 100 based on the test signal acquiredfrom the DUT connection section 280. Then, the DUT simulating section200 generates the result signal in simulation output as a result of theDUT 100 being operated based on the test signal, and supplies it to thetest module emulation section 270 through the DUT connection section280. The test module emulation section 270 compares the result signalwith the expected value, and acquires a comparison result.

Next, when the timing alignment section 276 outputs the test resultcollection timing registered in S625, the schedule section 277 notifiesthe test module emulation section 270 that the test result collectiontiming has come so as to collect acceptability of the result based onthe result signal supplied from the DUT simulating section 200 to thetest module emulation section 270 (S640). When the test resultcollection timing is notified, the test module emulation section 270notifies the synchronous module emulation section 250 through thesynchronous connection module emulation section 260 of the comparisonresult of the result signal and the expected value in the cycle time.The synchronous module emulation section 250 judges the acceptability(pass or fail) of the test result based on the comparison resultcollected from each of the test module emulation sections 270, andnotifies each of the test module emulation section 270 of theacceptability of a test result (S645). Based on the acceptability ofthis test result, the test program and the test data, which are suppliedto the plurality of test module emulation sections 270, are described soas to change the sequence of the test performed after the cycle time.

Next, when the timing alignment section 276 outputs the cycletermination timing in S625, the schedule section 277 notifies the testmodule emulation section 270 that that the termination timing of thecycle has come (S650).

Next, when the timing alignment section 276 outputs the interruptioncollection timing registered in S625, the schedule section 277 notifiesthe test module emulation section 270 that the interruption collectiontiming has come (S655). When the interruption collection timing isnotified, the test module emulation section 270 notifies in simulationthe site control emulation section 230 through the bus switch emulationsection 240 of the interruption, which is generated in simulation in thecycle time at which the test module emulation section 270 generates thetest signal just before the interruption collection timing.

The test emulator 190 repeats the processing explained in theabove-mentioned steps S600-S655 until the test is finished (S660).

In addition, when the test is done by the plurality of test moduleemulation sections 270, the schedule control section 275 aligns thetimings of each of the operations of the test module emulation sections270 in order of time, and makes the schedule. For this reason, S600,S630, S640, S650, and S655 about the plurality of test module emulationsections 270 are performed in order of time.

FIG. 7 is a drawing exemplary showing the test signal generated insimulation by the test emulator 190 according to the embodiment of thepresent invention. In this drawing, the test emulator 190 includes atest module emulation section 270 a for emulating a test module A, and atest module emulation section 270 b for emulating a test module B, asthe test module emulation section 270.

Before time t1, the test signal generating timing t1 of the test moduleemulation section 270 a, and the test signal generating timing t2 of thetest module emulation section 270 b are registered into the timingalignment section 276. Since the timings are to be output in order oftime, the test signal generating timing t1 is output at first. Inresponse to the result, the schedule section 277 notifies thesynchronous module emulation section 250 that the test signal generatingtiming t1 has come, while the time is set forward to t1.

When the test signal generating timing t1 is notified, the synchronousmodule emulation section 250 notifies the test module emulation section270 a corresponding to the test signal generating timing t1 through thesynchronous connection module emulation section 260 and the test moduleemulation section 270 of the start of the cycle. In response, testmodule emulation section 270 a generates the test signal in simulationin the cycle time indicated to be a cycle 1 in the figure. Here, testmodule emulation section 270 a notifies the DUT connection section 280that the test signal changes to H level at the change timing t4 in thecycle time. In response, the DUT connection section 280 registers thechange timing t4 into the timing alignment section 276.

Next, after the generation of the test signal in the cycle 1 isfinished, the test module emulation section 270 a notifies thesynchronous module emulation section 250 of the cycle end timing t6 ofthe cycle 1. In response, the synchronous module emulation section 250generates the test signal generating timing t6, the test resultcollection timing t6-Δ, the cycle termination timing t6-Δ, and theinterruption collection timing t6-Δ for the next time based on the cycleend timing t6, and registers them into the timing alignment section 276.Here, t6-Δ a time just before the next test signal generating timing t6.

Next, the timing alignment section 276 aligns the registered timings inorder of time, and outputs the test signal generating timing t2. Inresponse, the schedule section 277 sets time forward to t2 and notifiesthe synchronous module emulation section 250 that the test signalgenerating timing t2 has come.

When the test signal generating timing t2 is notified, the synchronousmodule emulation section 250 notifies the test module emulation section270 b corresponding to the test signal generating timing t2 through theschedule control section 275 of the cycle start. In response, testmodule emulation section 270 b generates the test signal of test moduleemulation section 270 b in simulation in the cycle 1. As a result, testmodule emulation section 270 b generates change timings of the testsignal t3 and t5, and the DUT connection section 280 registers thechange timings into the timing alignment section 276.

Next, test module emulation section 270 b notifies the synchronousmodule emulation section 250 of the cycle end timing t7 of the cycle 1after the generation of the test signal in a cycle 1 is finished. Inresponse, based on the cycle end timing t7, the synchronous moduleemulation section 250 generates the test signal generating timing t7,the test result collection timing t7-Δ, the cycle termination timingt7-Δ, and the interruption collection timing t7-Δ for the next time, andregisters them into the timing alignment section 276.

Next, the timing alignment section 276 aligns the registered timings inorder of time, and outputs the change timings t3, t4, and t5 one by one.According to each of the change timings, the schedule section 277notifies the DUT connection section 280 of the change timings. As aresult, the DUT connection section 280 changes the test signal insimulation during the change timing, and it is supplied to the DUTsimulating section 200.

Next, the timing alignment section 276 outputs the test resultcollection timing t6-Δ. In response, the schedule section 277 sets thetime forward to t6-Δ and notifies the test module emulation section 270a of the test result collection timing t6-Δ. As a result, collection anddistribution of the test result are performed between the test moduleemulation section 270 a and the synchronous module emulation section250.

Next, the timing alignment section 276 outputs the cycle terminationtiming t6-Δ. In response, the schedule section 277 notifies the testmodule emulation section 270 a of the end of the cycle 1.

Next, the timing alignment section 276 outputs the interruptioncollection timing t6-Δ. In response, the schedule section 277 notifiestest module emulation section 270 a of the outputs interruptioncollection timing t6-Δ. As a result, the test module emulation section270 a notifies the site control emulation section 230 of theinterruption generated in simulation in the cycle 1.

Next, the timing alignment section 276 outputs the test signalgenerating timing t6. In response, the schedule section 277 sets thetime forward to t6 and notifies the synchronous module emulation section250 that the test signal generating timing t6 has come. Henceforth, thetest emulator 190 generates the change timing t8, the result signalacquisition timing t11 indicating the timing at which the result signalis to be acquired, the test signal generating timing t12, the testresult collection timing t12-Δ, cycle termination timing t12-Δ, and theinterruption collection timing t12 for the next time in the similarmanner to the time t1. Then, the test emulator 190 registers thesetimings into the timing alignment section 276 in the similar manner tothe time t1.

Next, the timing alignment section 276 aligns the registered timings inorder of time, and outputs the test signal generating timing t7. Inresponse, the schedule section 277 sets the time forward to the t7 andnotifies the synchronous module emulation section 250 that the testsignal generating timing t7 has come. Henceforth, the test emulator 190generates the change timings t9 and t10, the test signal generatingtiming t13, the test result collection timing t13-Δ, the cycletermination timing t13-Δ, and the interruption collection timing t13 forthe next time in the similar manner to the time t2. Then, the testemulator 190 registers these timings into the timing alignment section276 in the similar manner to the time t2.

As described above, according to the test emulator 190 of the presentembodiment, the schedule control section 275 aligns various kinds oftimings, such as the test signal generating timing, the test signalchange timing, the test result collection timing, the result signalacquisition timing, and the interruption collection timing in order oftime, so that the scheduling is carried out. For this reason, the testemulator 190 appropriately emulates the operation of the test apparatus10 in case that the plurality of test modules 170 based on the differentcycles are mounted.

Alternatively, in the present embodiment, although the synchronousconnection module emulation section 260 registers the test resultcollection timing, the cycle termination timing, and the interruptioncollection timing into the timing alignment section 276 in case that thecycle end timing is received from the test module 170, The followingmethod is substituted for the above-mentioned method.

In S625 illustrated in FIG. 6, based on cycle end timing, thesynchronous module emulation section 250 generates the test signalgenerating timing at which the test module emulation section 270 is togenerate the test signal in simulation corresponding to the cycle time,and notifies the timing alignment section 276 of the timing andregisters the timing into the timing alignment section 276. On the otherhand at this time, the synchronous module emulation section 250 does notgenerate the test result collection timing, the cycle terminationtiming, and the interruption collection timing, and does not registerthem into the timing alignment section 276.

As a result, after the processing in the steps S630 and S635 is done,the test emulator 190 proceeds to the step S600 skipping the steps S640,S650, and S655. Moreover, in case that the timing alignment section 276outputs the test signal generating timing corresponding to the nextcycle time in S600, the schedule section 277 notifies the synchronousmodule emulation section 250 that the test signal generating timing hascome. In response, the synchronous module emulation section 250instructs the collection of the test result, the notice of the cycleend, and the collection of the interruption to the test module emulationsection 270 corresponding to the test signal generating timing beforethe generation of the test signal generating of the next cycle time.

According to the above-mentioned processing, the schedule controlsection 275 causes the synchronous module emulation section 250, thesynchronous connection module emulation section 260, test moduleemulation section 270 etc., to perform the processing described in S640,S645, S650, and S655 before the generation of the test signal of thenext cycle time. More specifically, the schedule control section 275causes the synchronous module emulation section 250 and the synchronousconnection module emulation section 260 to collect and distribute theacceptability of the test result based on the result signal supplied tothe test module emulation section 270 during the generation of the testsignal in the cycle time just before the test signal generating timing,and to notify the site control emulation section 230 of the interruptiongenerated in simulation by the test module emulation section 270.

Although the present invention has been described by way of an exemplaryembodiment, it should be understood that those skilled in the art mightmake many changes and substitutions without departing from the spiritand the scope of the present invention. It is obvious from thedefinition of the appended claims that embodiments with suchmodifications also belong to the scope of the present invention.

For example, the real test of the DUT 100 by the synchronous module 150,the synchronous connection module 160, the test module 170 and the like,and a simulation test of the DUT 100 by the synchronous module emulationsection 250, the synchronous connection module emulation section 260,the test module emulation section 270, the DUT simulating section 200and the like, are provided to a user of the test apparatus 10, which isexecutable by an identical test control program and/or the identicaltest program. Alternatively, the test mode of the test apparatus can beswitched between the real test and the simulation test manually by theuser.

That is for example, the site controller 130 inputs instructions ofselection between the real and simulation test of the DUT 100 as anoption of a test start command or the like. Then, when the instructionsorders to perform the real test of DUT 100, the system controller 110 orthe site controller 130 supplies a test program for the test of the DUT100 to one or a plurality of test modules 170 through the bus switch140, and causes the test module 170 to test the DUT 100. On the otherhand, when the instructions orders to perform the simulation test of theDUT 100, the site controller 130 supplies a test program to the testmodule emulation section 270 realized by software on the test emulator190 or the site controller 130 or the like, and causes the test moduleemulation section 270 or the like to simulate the test of the DUT 100.

In the embodiments described above, the site controller 130 may executecommunication software (communication library) which performscommunication processing between the control units and the test modules170 so that the real test environment and the simulation testenvironment may be accessible. In this case, the test control programexecuted by the site controller 130 performs the real test by using theidentical access functions (read/write function etc.) provided by thecommunication software, and by accessing the synchronous module 150, thesynchronous connection module 160, test module 170 and the like.Similarly, the test control program executed by the site controller 130performs the simulation test by using the identical access functionsprovided by the communication software, and by accessing the synchronousmodule emulation section 250, the synchronous connection moduleemulation section 260, the test module emulation section 270 and thelike. Here, the communication software described above, in cooperationwith the site controller 130, may select the destination of the testprogram between the test module 170 or the like and the test moduleemulation section 270 or the like based on the instructions about whichof the real test environment or the simulation test environment is to beselected. An example of such implementation is described further belowin supplementary information C.2.4.3.

Moreover for example, the test module emulation section 270 describedpreviously may include a configuration described below. First, each testmodule emulation section 270 receives signal for test signal generatingtiming scheduled by the schedule section 277 in the schedule controlsection 275 by function call. Then, each test module emulation section270 outputs variation of voltage of the test signal in the cycle timecorresponding to the test signal generating timing by calling voltagesetting methods (set methods) of the output channel object whichemulates the output channel multiple times. Then, after the output ofthe variation of voltage of the test signal corresponding to the cycletime is finished, the test module emulation section 270 notifies theschedule section 277 and the like that the output of the variation ofvoltage of the test signal corresponding to the cycle time has beenfinished by calling the end methods of the output channel object. Anexample of such implementation is described further below insupplementary information B.3.3 and the like.

Then, the schedule section 277 calculates a period during which all thetest module emulation sections 270 finishes the output of the variationof the voltage of the test signal based on the end methods notified fromeach of the plurality of test module emulation sections 270, and makesdemands on the DUT simulating section 200 for the simulation of theoperation of the DUT 100 during the period. In response, the DUTconnection unit 280 acquires the test signal during the period, andsimulates the operation of the devices under test based on the testsignal. As stated above, after the end methods are called, the outputchannel object forbids varying the voltage in the period during whichthe output of the variation of the voltage of the test signal isfinished, the variation of the voltage being notified by the endmethods. Thereby, the inconsistency of the simulation result which hasbeen already simulated can be prevented. An example of suchimplementation is described further below in supplementary informationB.3.4 and the like.

Described blow is the supplementary information on various kinds ofexamples and specifications for realizing the test apparatus 10 and thetest emulator 190 according to the present embodiment.

Supplementary information A: An Example of software architecture FIG. 8illustrates software architecture 2200 according to an embodiment of thepresent invention. The software architecture 2200 represents adistributed operating system, having elements for the system controller2200, at least one site controller 2240, and at least one module 2260 incorrespondence to related hardware system elements 110, 130, 150, 160and 170. In addition to the module 2260, the architecture 2200 includesa corresponding SW (software) module emulation 2280.

As an exemplary choice, the development environment for this platformcan be based on Microsoft Windows. The use of this architecture has sidebenefits in program and support portability (e.g., a field serviceengineer could connect a laptop which runs the tester operating systemto perform advanced diagnostics). However, for large compute-intensiveoperations (such as test pattern compiles), the relevant software can bemade as an independent entity capable of running independently to allowjob scheduling across distributed platforms. Related software tools forbatch jobs are thus capable of running on multiple platform types.

As an exemplary choice, ANSI/ISO standard C++ can be taken as the nativelanguage for the software. Of course, there are a multitude of optionsavailable (to provide a layer over the nominal C++ interfaces) thatallows a third party to integrate into the system with an alternativelanguage of its own choice.

FIG. 8 illustrates a shading of elements according to their organizationby nominal source (or collective development as a sub-system) includingthe tester operating system interfaces 2290, user components 2292 (e.g.,supplied by a user for test purposes), system components 2294 (e.g.,supplied as software infrastructure for basic connectivity andcommunication), module development components 2296 (e.g., supplied by amodule developer), and external components 2298 (e.g., supplied byexternal sources other than module developers).

From the perspective of source-based organization, the tester operatingsystem (TOS) interface 2290 include: System Controller to SiteController interfaces 2222; framework classes 2224; Site Controller toModule interfaces 2245; framework classes 2246, predeterminedmodule-level interfaces 2247, backplane communications library 2249,chassis slot IF (Interface) 2262, loadboard hardware IF 2264, backplanesimulation IF 2283, loadboard simulation IF 2285, DUT simulation IF2287, Verilog PLI (programming language interface) 2288 for DUT'sVerilog model and C/C++ language support 2289 for DUT's C/C++ model.

User components 2292 include: a user test plan 2242, user test classes2243, hardware loadboard 2265, and DUT 2266, a DUT Verilog model 2293and a DUT C/C++ model 2291.

System components 2294 include: system tools 2226, communicationslibrary 2230, test classes 2244, a backplane driver 2250, HW backplane2261 including the bus switch 140, simulation framework 2281, backplaneemulation 2282, and loadboard simulation 2286.

Module-development components 2296 include: module commandsimplementation 2248, module hardware 2263, and module emulation 2284.

External components 2298 include external tools 2225.

The system controller 2200, which is software operated on the test sites2110 illustrated in FIG. 1, includes interfaces 2222 to site controller,framework classes 2224, system tools 2226, external tools 2225, and acommunications library 2230. The System Controller software is theprimary point of interaction for the user. It provides the gateway tothe Site Controllers of the embodiment, and synchronization of the SiteControllers in a multi-site/DUT environment as described in U.S.application No. 60/449,622 by the same assignee. User applications andtools, graphical user interface (GUI)-based or otherwise, run on theSystem Controller. The System Controller also may act as the repositoryfor all Test Plan related information, including Test Plans, testpatterns and test parameter files. A test parameter file containsparameterization data for a Test class in the object orientedenvironment of an embodiment of the embodiment.

Third party developers can provide tools in addition to (or asreplacements for) the standard system tools 2226. The standardinterfaces 2222 on the System controller 2200 include interfaces thatthe tools use to access the tester and test objects. The Tools(applications) 2225, 2226 allow interactive and batch control of thetest and tester objects. The tools include applications for providingautomation capabilities (through, for example, the use of SECS/TSEM,etc.)

The Communications library 2230 residing on the system controller 2200provides the mechanism to communicate with the Site Controllers 2240 ina manner that is transparent to user applications and test programs.

The Interfaces 2222 resident in memory associated with the Systemcontroller 2200 provide open interfaces to the framework objects thatexecute on the System Controller. Included are interfaces allowing theSite Controller-based module software to access and retrieve patterndata. Also included are interfaces that applications and tools use toaccess the tester and test objects, as well as scripting interfaces,which provide the ability to access and manipulate the tester and testcomponents through a scripting engine. This allows a common mechanismfor interactive, batch and remote applications to perform theirfunctions.

The Framework Classes 2224 associated with the System controller 2200provide a mechanism to interact with these above-mentioned objects,providing a reference implementation of a standard interface. Forexample, the site controller 2240 of the embodiment provides afunctional test object. The system controller framework classes mayprovide a corresponding functional test proxy as a remote systemcontroller-based surrogate of the functional test object. The standardfunctional test interface is thus made available to the tools on thesystem controller 2200. The system, module-development and interfacecomponents 294, 296 and 290, respectively, may be considered anoperating system distributed between the system controller and the sitecontrollers. The framework classes effectively provide an operatingsystem interface associated with the host system controller. They alsoconstitute the software elements that provide the gateway to the SiteControllers, and provide synchronization of the Site Controllers in amulti-site/DUT environment. This layer thus provides an object model inan embodiment of the invention that is suitable for manipulating andaccessing Site Controllers without needing to deal directly with theCommunications layer.

The site controller 2240, which is software operated on the sitecontrollers 130 illustrated in FIG. 1, hosts a user test plan 2242, usertest classes 2243, standard test classes 2244, standard interfaces 2245,site controller framework classes 2246, module high level commandinterfaces (i.e., predetermined module-level interfaces) 2247, modulecommands implementation 2248, backplane communications library 2249, anda backplane driver 2250. Preferably most of the testing functionality ishandled by the site controllers 2104/2240, thus allowing independentoperation of the test sites 2110.

A Test plan 2242 is written by the user. The plan may be writtendirectly in a standard computer language such as C++, or described in ahigher level test programming language to produce C++ code, which canthen be compiled into the executable test program.

The test plan creates test objects by using the Framework Classes 2246and/or standard or user supplied Test Classes 2244 associated with thesite controllers, configures the hardware using the Standard Interfaces2245, and defines the test plan flow. It also provides any additionallogic required during execution of the test plan. The test plan supportssome basic services and provides an interface to the services ofunderlying objects, such as debug services (e.g., break-pointing), andaccess to underlying framework and standard classes.

The Framework classes 2246 associated with the site controllers are aset of classes and methods that implement common test-relatedoperations. The site controller-level framework includes, for example,classes for power supply and pin electronics sequencing, setting leveland timing conditions, obtaining measurements, and controlling testflow. The framework also provides methods for runtime services anddebugging. The framework objects may work through implementing thestandard interfaces. For example, the implementation of the TesterPinframework class is standardized to implement a general tester pininterface that test classes may use to interact with hardware modulepins.

Certain framework objects may be implemented to work with the help ofthe module-level interfaces 2247 to communicate with the modules. Thesite controller framework classes effectively act as a local operatingsystem interface supporting each site controller.

In general more than ninety percent of the program code is data for thedevice test, and the remaining ten percent of the code realizes the testmethodology. The device test data is DUT-dependent (e.g., power supplyconditions, signal voltage conditions, timing conditions, etc.). Thetest code consists of methods to load the specified device conditions onto ATE hardware, and also those needed to realize user-specifiedobjectives (such as datalogging). The framework of an embodiment of theinvention provides a hardware-independent test and tester object modelthat allows the user to perform the task of DUT test programming.

To increase the reusability of test code, such code may be madeindependent of any device-specific data (e.g., pin name, stimulus data,etc.), or device-test-specific data (e.g., conditions for DC units,measurement pins, number of target pins, name of pattern file, addressesof pattern programs). If code for a test were compiled with data ofthese types, the reusability of the test code would decrease. Therefore,according to an embodiment of the invention, any device-specific data ordevice-test-specific data may be made available to the test codeexternally, as inputs during code execution time.

In an embodiment of the invention, a Test Class, which is animplementation of a standard test interface, denoted here as ITest,realizes the separation of test data and code (and hence, thereusability of code) for a particular type of test. Such a test classmay be regarded as a “template” for separate instances of itself, whichdiffer from each other only on the basis of device-specific and/ordevice-test-specific data. Test classes are specified in the test planfile. Each Test class typically implements a specific type of devicetest or setup for device test. For example, an embodiment of theinvention may provide a specific implementation of the ITest interface,for example, FunctionalTest, as the base class for all functional testsfor DUTs. It provides the basic functionality of setting testconditions, executing patterns, and determining the status of the testbased on the presence of failed strobes. Other types of implementationsmay include AC and DC test classes, denoted here as ACParametricTestsand DCParametricTests.

All test types may provide default implementations of some virtualmethods (e.g., init( ), preExec( ), and postExec( )). These methodsbecome the test engineer's entry points for overriding default behaviourand setting any test-specific parameters. However, custom test classescan also be used in test plans.

Test classes allow the user to configure class behaviour by providingparameters that are used to specify the options for a particularinstance of that test. For example, a Functional Test may takeparameters PList and TestConditions, to specify the Pattern List toexecute, and the Level and Timing conditions for the test, respectively.Specifying different values for these parameters (through the use ofdifferent “Test” blocks in a test plan description file) allows the userto create different instances of a Functional Test. FIG. 4 illustrateshow different test instances may be derived from a single test class. ATemplate Library may be employed as the general-purpose library ofgeneric algorithms and data structures. This library may be visible to auser of the tester, so that the user may, for example, modify theimplementation of a test class to create a user-defined test class.

As to user-developed test classes, an embodiment of the system supportsintegration of such test classes into the framework in that all testclasses derive from a single test interface, e.g., ITest, so that theframework can manipulate them in the same way as the standard set ofsystem test classes. Users are free to incorporate additionalfunctionality into their test classes, with the understanding that theyhave to use custom code in their test programs to take advantage ofthese additional facilities.

Each test site 2110 including the site controller 130, the synchronousmodule 150, the synchronous connection module 160 and the test module170 is dedicated to testing one or more DUTs 100, and functions througha configurable collection of test modules such as the test module 170.Each test module is an entity that performs a particular test task. Forexample, a test module could be a DUT power supply, a pin card, ananalogue card, etc. This modular approach provides a high degree offlexibility and configurability.

The Module Commands Implementation classes 2248 may be provided bymodule hardware vendors, and implement either the module-levelinterfaces for hardware modules, or provide module-specificimplementations of standard interfaces, depending on the commandsimplementation method chosen by a vendor. The external interfaces ofthese classes are defined by pre-determined module level interfacerequirements, and backplane communication library requirements. Thislayer also provides for extension of the standard set of test commands,allowing the addition of methods (functions) and data elements.

The Backplane Communications Library 2249 provides the interface forstandard communications across the backplane, thereby providing thefunctions necessary to communicate with the modules connected to thetest site. This allows vendor-specific module software to use aBackplane Driver 2250 to communicate with the corresponding hardwaremodules. The backplane communications protocol may use a packet basedformat.

Tester Pin objects represent physical tester channels and derive from atester pin interface, denoted here as ITesterPin. The softwaredevelopment kit (SDK) of an embodiment of the invention provides adefault implementation of ITesterPin, which may be called TesterPin,which is implemented in terms of a predetermined module-level interface,IChannel. Vendors are free to make use of TesterPin if they canimplement their module's functionality in terms of IChannel; otherwise,they must provide an implementation of ITesterPin to work with theirmodule.

The standard module interface, denoted here as IModule, provided by thetester system of the embodiment generically represents a vendor'shardware module. Vendor-supplied module-specific software for the systemmay be provided in the form of executables such as dynamic linklibraries (DLLs). Software for each module-type from a vendor may beencapsulated in a single DLL. Each such software module is responsiblefor providing vendor-specific implementations for the module interfacecommands, which comprise the API for module software development.

There are two aspects of the module interface commands: first, theyserve as the interface for users to communicate (indirectly) with aparticular hardware module in the system, and second, they provide theinterfaces that third-party developers can take advantage of tointegrate their own modules into the site controller level framework.Thus, the module interface commands provided by the framework aredivided into two types:

The first, and most obvious, are those “commands” exposed to the userthrough the framework interfaces. Thus, a tester pin interface(ITesterPin) provides methods to get and set level and timing values,while a power supply interface (IPowerSupply) provides methods forpowering up and powering down, for example.

In addition, the framework provides the special category of thepredetermined module-level interfaces, which can be used to communicatewith the modules. These are the interfaces used by framework classes(i.e., “standard” implementations of framework interfaces) tocommunicate with vendor modules.

However, the use of the second aspect, the module-level interfaces, isoptional. The advantage of doing so is that vendors may then takeadvantage of the implementations of classes such as ITesterPin andIPowerSupply, etc. while focusing on the content of specific messagessent to their hardware by implementing the module-level interfaces. Ifthese interfaces are inappropriate to the vendor, however, they maychoose to provide their custom implementations of the frameworkinterfaces (e.g., vendor implementations of ITesterPin, IPowerSupply,etc.). These would then provide the custom functionality that isappropriate for their hardware.

The integration of module-specific vendor software can thus beaccomplished through two different means: custom implementation ofrelevant framework classes and interfaces, or custom implementation ofthe special category of module level interfaces.

An example application of both methods is next presented with the aid ofFIG. 10, which is a Universal Modelling Language (UML) class diagramdepicting the interaction of the tester system of an embodiment of theinvention and vendor-supplied modules.

A vendor of a new digital module, Third Party A (TPA), provides asoftware module to communicate with its hardware module. This softwaremodule will implement the standard interface, IModule. Let this moduleobject be called TPAPinModule. The vendor TPA is able to make use of thestandard system implementation of the ITesterPin interface, denoted hereas TesterPin, by implementing the relevant predetermined module-levelinterface—in this case, IChannel—in its module. This is made possible bythe fact that TesterPin uses standard predetermined module-levelinterfaces, such as IChannel, to communicate with modules. Therefore,TPAPinModule provides pins by simply creating and exposing TesterPinobjects.

Now consider a different vendor, Third Party B (TPB), who decides thatthe IChannel interface does not work well with its hardware. Therefore,TPB needs to provide not only its own IModule implementation(TPBPinModule), but also an implementation of the ITesterPin interface,TPBTesterPin.

This approach gives third party developers a great deal of flexibilityin choosing how to develop their hardware and supporting software. Whilethey are required to implement the IModule interface, they may choose toimplement module level interfaces or implement objects like TesterPins,as they see fit.

In fact, vendors may choose to implement TesterPins in order to provideextensions that are not supported in the ITesterPin interface. Theframework will provide users a mechanism for retrieving a specificinterface or implementation pointer to an object. This means that whenuser code has an ITesterPin pointer, the framework will be able todetermine if it is pointing to, say, a TPBTesterPin object if it needsto. (Note that this feature may be provided via standard C++ Run TimeType Identification (RTTI).) In other words, when the test plan calls onthe ITesterPin interface, the interface may, in turn, directly invokethe vendor's tester pin implementation of the TesterPin class, whichincorporates module-specific information (e.g., addresses of registersto be set to provide a particular DUT stimulus).

In summary, while the framework code will always use the ITesterPininterface, users are free to make use of specific features andextensions provided by module vendors as needed. In other words, amodule vendor can, for example, add methods (functions) to the standardsystem implementation of the class. The tradeoff for the user is thattaking advantage of specific vendor extensions makes the test code lessuseable with other vendors' modules.

At the modular level, the test apparatus 10 nominally has two modes ofoperation. In an online mode of operation, module elements 2260 (e.g.,hardware elements), which include the bus switch 140, the synchronousmodule 150, the synchronous connection module 160, the test module 170,the load board 180 and the DUT 100, are used, and in an offline mode ofoperation module emulation in software 2280, which includes the busswitch emulation section 240, the synchronous module emulation section250, the synchronous connection module emulation section 260, the testmodule emulation section 270, the schedule control section 275, the DUTconnection section 280, and the DUT simulating section 200, is used.

For the online mode of operation, the module element 2260 includes HW(hardware) backplane 2261 including the bus switch 140 illustrated inFIG. 1, chassis slot IF (Interface) 2262, module hardware 2263 includingthe synchronous module 150, the synchronous connection module 160, thetest module 170 and the like, loadboard hardware IF 2264, hardwareloadboard 2265 which corresponds to the load board 180, and DUT 2266which corresponds to the DUT 100 illustrated in FIG. 10.

For the offline mode of operation, the module emulation in software 2280includes a simulation framework 2281 including the schedule controlsection 275 illustrated in FIG. 2, backplane emulation 2282 includingthe bus switch emulation section 240, backplane simulation IF 2283,module emulation 2284 including the synchronous module emulation section250, the synchronous connection module emulation section 260, the testmodule emulation section 270 and the like, loadboard simulation IF 2285,loadboard simulation 2286 including the DUT connection section 280, andDUT simulation IF 2287. Two models are shown for DUT simulation. A modelusing Verilog includes the Verilog PLI (Programming Language Interface)2288 and a DUT Verilog model 2293. A model using C/C++ includes C/C++language support 2289 and a DUT C/C++ model 2291. Note that thesimulation can be performed on any computer, e .g., a PC.

In the online mode, the Module vendors provide physical hardwarecomponents to support testing, such as digital tester channels, DUTpower supplies, or DC measurement units. The modules interface to the HWbackplane 2261 through the chassis slot IF 2262.

For offline work, a PC-based or other environment that runs theequivalent of the System Controller would, additionally, undertake allthe responsibilities of providing the Site Controller-level frameworkand runtime environment for the lower layers of software, as well asemulating hardware.

The backplane emulation 2282 provides a software surrogate for thephysical backplane 2261. This communicates with the (vendor-supplied)module emulation software 2284 through the backplane simulationinterface 2283.

The module emulation software 2284 is preferably provided by the modulevendor, and is typically closely tied with a particular vendorimplementation of a module 2263. Thus, the module emulation softwarewill typically differ in the details across modules supplied bydifferent vendors. In this case, the module simulation allows the vendorto expose hardware functionality through a software model (e.g., themodule emulation software 2284), send stimulation signals to thesimulated loadboard 2286, and receive and process DUT response signalsfrom the simulated loadboard 2286, which is connected to DUT modellingsoftware 2291, 2293 through the DUT simulation IF 2287. In some cases,vendors may find it advantageous to provide a simple functionalsimulation of the module and bypass emulation of the module firmware.The module emulation software compares the response of the simulated DUTto the simulated-module stimulation signals with a known good DUTresponse. Based on this comparison, the software determines whether thetest being executed by the module meets its goal of testing the DUT asdesired, and helps the user to debug the module prior to using it on anIC (physical DUT) on the online physical tester.

The loadboard simulation interface 2285 serves as the conduit forsignals to and from the module emulation layer and the simulatedloadboard 2286. The loadboard simulation component 2286 supports devicesocket mapping and signal propagation to and from the DUT simulation IF2287.

The DUT simulation may be a native code (i.e., C/C++) simulation 2291,or a Verilog Programming Language Interface (PLI) to a functional modelof the target device under test 2293. The model interfaces with thesimulated loadboard through the DUT simulation interface 2287.

Note that the overall control of these layers is provided by thesimulation framework 2281. The simulation framework measures thesimulated DUT response to known stimulation signals. The method ofsystem emulation is disclosed in U.S. application Ser. No. 10/403,817.

Communication and Control

Communication and control are carried out through management of relatedsoftware objects. Preferably, a communications mechanism is hiddenbehind an object model on the system controller. This object modelprovides a proxy to the classes and objects found on the site controllerand thereby provides a convenient programming model for applicationdevelopment (e.g., IC device testing). This allows applicationdevelopers (e.g., users of the ATE system) to avoid unnecessary detailsrelated to the specifics of communications between the application andthe Site/System controllers.

FIG. 11 illustrates a specific embodiment of a site controller object asmaintained in site controller software 2240 of the site controller 130.The site controller object includes CmdDispatcher 2602,FunctionalTestMsgHandler 2604 and FunctionalTest 2606. Interfacesinclude IMsgHandler 2608 and ITest 2610.

The site controller software 2240 preferably contains all of thefunctional classes that an application may need for access. Theseclasses may, for example, include Tests, Modules, Pins, etc. Since theuser's tests and software tools typically reside on different computers,messages will be sent from the tools on the System Controller to aserver on the Site Controller. This server will call a method on aCommand Dispatch object.

The Command Dispatch object (CmdDispatcher) 2602 maintains a map ofmessage handler objects, which implement the IMsgHandler interface 2608.FIG. 11 illustrates a specific implementation of IMsgHandler,FunctionalTestMsgHandler 2604.

Messages received by the CmdDispatcher object 2602 contain an identifierof the object to be communicated with. This identifier is found in aninternal map, which resolves to the specific implementation, in thiscase the FunctionalTestMsgHandler object 2604 shown.

In this example, IMsgHandler 2608 consists of a single method,handleMessage( ). This method is preferably implemented as a singleimplementation class. In the case shown, the FunctionalTestMsgHandler2604 will forward the message on to one of six methods depending on theexact nature of the incoming message. The header of the incoming messagecontains a message id which allows the message handler to decide how tointerpret and where to forward the message.

The corresponding communications environment at the system controller110 relates to the tools 2225, 2226 section of the system controllersoftware 2220. FIG. 12 illustrates an embodiment of a tool object (orsystem controller object) maintained on the system controller 110 insystem controller software 2220 in correspondence to the site controllerobject shown in FIG. 11. The tool object includes an objectCmdDispatcher 2702, FunctionalTestMsgHandler 2704 andFunctionalTestProxy 2706. Interfaces include IMsgHandler 2708,ITestClient 2710, and IDispatch 2712. Also included is a utilityApplication 2714.

For this example, the classes CmdDispatcher 2702, IMsgHandler 2708, andFunctionalTestMsgHandler 2704 are the same as in FIG. 11. However,instantiations of FunctionalTest 2606 (or any other site-controllerclass) are not used. Instead, the tool object has proxy classes forcommunication with each object on the site controller 130. Therefore,for example, the tool object includes the class FunctionalTestProxy 2706in the place of FunctionalTest 2606. Similarly, ITestClient 2710 in thetool object is not the same as ITest 2610 in site controller object. Ingeneral, applications running on the site controller 130 will not usethe exact interfaces as provided on the site controller 130. In thiscase, three methods of ITest 2610 (namely preExec( ), execute( ), andpostExec( )), are replaced with a single method in ITestClient 2710(namely runTest( )). In addition, ITestClient 2710 is a preferably dualinterface; that is, it inherits from IDispatch 2712, which isimplemented as a Microsoft Component Object Model (COM). It provides aninterface that enables a scripting engine to access the objectimplementing that interface. This allows the system to be scriptable onthe Microsoft Windows platform.

As an example for operation of the embodiments shown in FIGS. 11-12, anapplication running on the system controller 110 (e.g., in one of thetools sections 2226, 2228) may communicate with a site controller 130where a test plan 2242 includes one or more FunctionalTest objects 2606.During initialization of the test plan 2242 on the site controller 130,a corresponding test-plan object is loaded onto the site controller 130,which constructs a TestPlanMessageHandler object and registers it withthe CmdDispatcher object 2602. This assigns a unique ID to the messagehandler. Similar operations occur with other TestPlan objects that makeup the test plan 2242.

The application (e.g., in tools 2226, 2228) on the system controller 110initializes the communication library 2230, connects to the sitecontroller 130 via a communication channel, and gets an ID for theTestPlan object. The library constructs a TestPlanProxy object andinitializes it with this ID. During initialization this proxy objectdetermines how many Tests it contains and their types and IDs. It loadsthe appropriate DLLs for each type (in this case only one type) andconstructs the proxy objects for them, initializing them with their IDvalues.

The Test Proxy objects, in turn, also initialize. To do this theyconstruct appropriate messages to get their names (using their IDvalues) and send them to a communication server at the site controller130, which passes the message on to the CmdDispatcher 2602. This objectlooks up the destination IDs in its internal map and forwards themessage on to the handleMessage( ) methods of theFunctionalTestMsgHandler objects 604. For example, if the message was arequest to obtain test names, these objects get their respective test'snames and reply to the application's Test Proxy objects with theappropriate name strings.

After initialization has completed, the application has remote access toa TestPlan object and through it, both Test objects. The user may nowpresses for example, a “Run Test Plan” button on the application. As aresult, the application calls the RunTestPlan( ) method on the Test PlanProxy object. This method constructs a RunTestPlan message with thedestination ID of the Test Plan object and calls the sendMessage( )function on the RPC proxy, which sends the message to the SiteController.

The communication server on the site controller 104 calls thehandleMessage( ) method on the CmdDispatcher object 2602 passing it theID of the Test Plan object. The CmdDispatcher object 2602 looks up thisID in its internal map, finding the message handler for the TestPlanobject and calls the handleMessage( ) method on this object, which, inturn, calls the RunTestPlan( ) method on the TestPlan object. In asimilar manner, the application can get the names and last run status ofthe Test objects.

Method for Using the Communication Library

The following is an example use of the communications library 2230.

The communication library 2230 is preferably a static library. Anapplication can use this communication library through a CommLibrary.hfile. An application that needs to export the communication libraryclasses should have the preprocessor definitions COMMLIBRARY_EXPORTS,COMMLIBRARY_FORCE_LINKAGE defined in addition to including the aboveinclude file. An application that imports the communication library neednot define any preprocessor definitions. When the communication libraryis used as server, the application has to call the following staticfunction of CcmdDispatcher: InitializeServerunsigned long portNo).

The portNo is the portNo on which the server should be listening. Thecommand dispatcher corresponding to the server can be retrieved bycalling the static function: getServerCmdDispatcher on theCCmdDispatcher class.

When the communication library is used as client the application shouldcall the static function “InitializeClientconst(const OFCStringserverAddress, unsigned long serverPortNo, CcmdDispatcher**pCmdDispatcher, OFCString serverId)”.

The serverAddress and ServerPortNo to which the client has to connect.This function initializes the command dispatcher pointer for the clientand serverId to which it has connected. Also at a later point of timethe client can retrieve the command dispatcher corresponding to theserverId by calling the static function getClientCmdDispatcher.

When the communication library is being compiled, the build has beenexcluded on the files ClientInterface.idl and Serverlnterface.idl. Thepreferred embodiment applies the already generated stub and proxy filesfor these interface definition files to link the proxy and stubimplementation files into the same library. Hence, the server and clientcan be instantiated in the same address space. The following changes inthe interface definition files and stub files are preferably made tomake the communication library work as server and client in the sameaddress space.

Changes in Interface Definition Files

The following namespace declaration is preferably added in each of theinterface definition files. This is to avoid the name collision betweenthe proxy implementation functions and our own implementation of theinterface functions. The following namespace declaration is added in theserverInterface.idl.

The functions in the stub implementation file is changed to call our ownimplementation functions for the functions that are declared in theinterfaces i.e. we have a different named function corresponding to eachof the functions that are declared in the interfaces.

In order to avoid the conflict in function call, it is preferable toprefix the implementation functions names with “COMM_” string. So thecode in the stub functions is changed to call “COMM_functionName”instead of “functionName”.

For this method to work, all the functional classes that exist, shouldalso have their corresponding message handler object and Proxy classes.All message handler objects should derive from IMsgHandler classprovided by the communication library. IMsgHandler class is an abstractclass. It is preferably the responsibility of the implementer of themessage handler to provide a definition for the handleMessage,setObjectId, handleError. All the message types should start from one(we reserve zero for handleError). The functional class preferably havetheir corresponding message handler as their member variable. In theconstructor of the functional class, the functional class should getitself registered with the message handler by calling a functionprovided by its message handler. Next the message handler object shouldbe registered with the command dispatcher by calling addMsgHandlerfunction on the command dispatcher with the message handler as theparameter. The addMsgHandler function will assign an ID to the messagehandler and the functional class. The destructor of the functional classshould call the removeMsgHandler function on the command dispatcher bysending the function class identifier as parameter. Proxy classes shouldalso follow the same procedure of registration as explained for thefunctional classes.

System Configurations and Testing

FIG. 13 illustrates a nominal testing sequence 2800 according to anembodiment of the present invention. The testing sequence 2800 includesinstallation 2815 of modules in a test environment 804 that encompassestest preparation 2806 and system testing 2808. Initially a new module(hardware or software or a combination thereof) 2810 is certified 2812(by some external procedure possibly based on vendor quality control).Installation 2815 first requires test preparation 2806 includinginstallation of hardware module emulation for offline simulation 2809,installation of module resource files and interfaces for test programdevelopment 2814 and installation of module specific pattern compilerfor pattern compilation 2816. Next system testing 2808 is carried outwith inputs from calibration 2817, diagnostics 2818, and configuration.System testing 2808 then is carried out for the new module including:(1) interface control, (2) synchronization, sequencing andrepeatability, (3) error/alarm handling, (4) multi-site control, and (5)multi-instrument module control.

Supplementary Information B: an example of specification of a frameworkof the system software of the DUT 100.

B.1 Introduction

This specification is a guide for user and developer which describes aframework of system software of the DUT 100 focusing on the emulationenvironment (offline environment) by the distributed system of the testemulator 190 or the system controller 110, and the site controller 130.

B.2 User's Guide

This chapter is a user's guide which describes the framework of thesystem software of a test apparatus 10.

B.2.1 SimTester

“SimTester (simulated test apparatus)” is an application program causingthe computer 20 to act as the test emulator 190 illustrated in FIG. 2.SimTester loads all module and DUT DLLs and responds to commands fromthe system software and emulates the test apparatus, where the systemsoftware is runtime software to simulate pattern load and execution.

When SimTester is brought up, it loads the Simulation ConfigurationFile. This results in the loading of all Module Emulation DLLs whichcause the test emulator 190 as the synchronous module emulation section250, the synchronous connection module emulation section 260, and thetest module emulation section 270. After loading the DLLs, SimTesterwaits for a connection from the system controller 110. The systemcontroller 110 connects to SimTester when a test plan is loaded. Part ofthe information in the test plan is the name of the OfflineConfiguration File. Before the system controller 110 actually loads thetest plan data, it sends the Offline Configuration File to SimTester sothat it can complete its initialization. A successful load of theOffline Configuration File means that SimTester has loaded the DUTmodels and has attached them to the module emulator such as the testmodule emulation section 270 as the DUT connection section 280 and theDUT simulating section 200. At this point the simulation is ready forpattern loading and after that pattern execution.

When a test plan is unloaded, SimTester is signalled to unload the DUTmodels and wait for a new Offline Configuration File.

B.2.2 Configuration Files

SimTester uses 2 configuration files. The first is the simulationconfiguration file. This file specifies what tester modules will beavailable during the simulation. The second file is the offlineconfiguration file. This file specifies what DUT models will be loadedand how they are connected to the tester.

B.2.2.1 Simulation Configuration Files

FIGS. 14-15 are examples of a simulation configuration file. The file isbroken up into hierarchical blocks.

The global section 5010 performs global setting. The InitVoltageparameter is the initial voltage on all the wires in the simulation atthe start. Subsequent patterns start with the state left on the wire bythe previous pattern.

The RecoveryRate parameter is an optional parameter used to resolve twoanalogue signals driving against once another. More specifically, theparameter indicates voltage variation per a predetermined time used todetermine how long it takes a voltage to achieve its steady state levelwhen this case arises.

The module emulation section 5020 specifies module DLL, and sets up themodule DLL.

The Waveform Section declares what types of waveform models are used foreach module resource. The waveform model, such as step waveform, slewwaveform, analogue waveform or the like, is specified for each channelconnecting with a terminal of the DUT

A port section declares instance of the module emulator which causes thetest emulator 190 to acts as the synchronous module emulation section250, the synchronous connection module emulation section 260, the moduleemulation section 270 and/or the like.

The LogicalPort parameter is provided such that when a module insertedin a channel is replaced to another channel due to the fail of thechannel, the LogicalPort parameter keeps about the replacement.

The Params section in the module emulation section 5020 keeps theparameter to be passed to the module DLL.

B.2.2.2 Offline Configuration File

FIGS. 16-17 are examples of offline configuration files. The globalsection 5110 performs an overall setup. RegSelect specifies a file whichselects the register to be traced for pattern tracing.

Waveform parameter sets up a waveform model for every terminals of eachDUT. DUT block mainly includes Params Block and PinConnections Block.

The PinConnections Block specifies connection between resource of thetest apparatus and a terminal of the DUT. For example, “L3.11 10 1.0ns”indicates that Resource 11 of LogicalPort 3 is connected to DUT pin 10,with a transport delay of 1.0 nanoseconds. Here, the LogicalPort is aport where a module is implemented, and the Resource is logic or thelike which corresponds to a channel provided in the module etc.

B.3 Developer's Guide

Tester module and DUT models are created by the framework of the moduleemulation program illustrated in FIG. 5, e.g., by deriving C++ classesfrom some base classes. The derivation involves implementing a fewvirtual functions in the base class. In addition, the framework providessome classes that facilitate I/O between tester modules and DUT models.Finally, by implementing the framework, the obtained DLL can beconnected to another component in the test emulator 190 to run theemulation.

B.3.1 Offline Framework Class Structure

FIG. 18 is a class hierarchical structure 5200 illustrating the detailof the class hierarchical structure illustrated in FIG. 5. Each methodin ThirdPartyModule class and ThirdPartyDUT classes are the virtualmethods that must be implemented to define the behaviour of the model.The createDomain, registerDomain, releaseDomain, getDomain,registerEvent and raiseEvent methods in the SimComponent base classprovides service for accessing the software simulation engine of the DUT100 which causes the test emulator 190 to acts as the schedule controlsection 275 or the like.

FIG. 19 illustrates a specification diagram of the channel object usedas an interface in the framework. Tester modules and DUT models willcontain an array of SimChannel objects. Each instance of SimChannelcorresponds to an I/O channel for the model. Channels are identifiedusing SimChanID objects. The SimChannel class allows the module or DUTmodel to write the voltage time history to the output channel, and toread voltages at specific times from input channels. If an input channelneeds to be scanned for edges in a time window, then an instance of aSimWaveformIter can be obtained from the SimChannel::getWaveformltermethod. The SimWaveformIter object allows the calling routine to iteratethrough all the edge in a finite time window.

B.3.2 Implementation of a Tester Module

In this section, implementation of simple digital driver module anddigital strobe module will be explained as examples of moduleimplementing method.

FIG. 21 shows base class of simple digital module as an example of themodule of the test apparatus. The class of the digital driver module andthe digital strobe module is generated as a derived class of the baseclass.

The developer implements constructor of the base class, getChannelmethod which returns the channel object, setBaseAddress which sets upmemory address space of the module, setBusNumber method which sets upthe slot number of the bus switch 140, lockInterrupt/unlockInterruptmethod which sets up lock/unlock of interruption, the read/write methodwhich accesses the memory address space in the modular based on the baseclass.

B.3.2.1 Local Events

Offline simulation is an event driven process. That is, each moduleregisters events. Then, the handleEvent method of the module of whichthe event is registered is called.

The events are defined by the SimEvent class and classified intosynchronous events and asynchronous events. Asynchronous events arefurther classified into system events and local asynchronous events.System events are for example, system interruption, end of patterngeneration, etc.

B.3.2.1.1 Local Asynchronous Events

Local asynchronous events are used to handle inter-modulecommunications. As the name applies there is no time associated withthis event. To indicate that a module wishes to receive a particularasynchronous event, it should register for it through the overloadedregisterEvent method that takes no time argument. If a module needs toraise an event, the raiseEvent method should be invoked. Note that theevent object supports arguments to be added to an event. The receivingmodule should handle asynchronous events in the overloaded handleEventmethod that has no time argument.

B.3.2.1.2 Local Synchronous Events

The most common type of event used is the local synchronous event (orsimply synchronous event). These events are used by modules to scheduleread or write (drive or strobe for digital modules) events. Synchronousevents are only used by a module to receive notification at a specifictime, and are never used for inter-module communications.

B.3.3 Simple Digital Driver Module

FIG. 22 illustrates class declaration of a simple digital driver module.The developer implements getModuleIDs method which returns informationon the constructor and vendor/module of the class, and initEvents methodwhich initializes the driver module.

FIG. 23 is an example of the handleEvent method of the digital drivermodule.

The drive module writes edges for all the channels in the current cycle.This writing is performed by the set method in each element ofm_channels, which is an array of SimChannel objects. In addition to theset method, the SimChannel objects include off method and end method.The off method stops drive of the signal. The end method notifies theframework that the generation of the signal during a predeterminedperiod, e.g., cycle period, is finished. On receiving the notification,a signal which instructs read-out of a channel is sent to a componentopposite from the channel. e.g., to the DUT connection unit 280.Consequently, the generated signal is read by the component. Typically,in order to generate and transfer the signal during the predeterminedperiod, the user will make several set-method calls to specify thevoltage over a time range, and then call end method once at the end ofthe predetermined period. The relation between the set method and theend method will be described in detail in B.3.4.

B.3.4 Simple Digital Strobe Module

FIG. 24 shows class declaration of a simple digital strobe module. Thedeveloper implements constructor, getModuleID method, initEvents method,etc., in a similar manner to the digital driver module. As for thedigital strobe module, since the comparison result of the output valueof the DUT and an expected value is stored in fail memory, read andwrite methods are changed.

FIG. 25 is an example of the handleEvent method of the digital strobemodule.

A digital strobe module reads the voltage of the channel in specifictiming using the read method of the SimChannel. Then, after finishingthe processing during the cycle period, it request the SimEventMgrobject to create an event by sending the end timing of the next cycle,then the event is registered by the registerEvent method.

B.3.4 Implementation of a DUT Model

DUT modelling uses the same approach as tester modules; however, thesimulation of DUTs is not event driven. Hence, SimComponentStepped thebase class for DUT models, supplies implementations for initEvents,handleEvent, and bus I/O methods. Instead the function run must beimplemented to define the DUT model behaviour during pattern execution.

FIG. 27 shows an example of the run method in the DUT model. The runmethod takes two arguments, a start time and an end time. Thesearguments indicate that the DUT model should advance its internal statesfrom the start time to the end time based upon stimulus from the inputpins and output any data resulting from these changes to the DUT state.Inputs should be received from the SimChannel objects. In addition,outputs can occur after the end time.

The run method includes steps of scanning the input terminals, updatingthe internal states of the DUT, and outputting data to the outputchannels of the DUT.

Even if an output edge were to fall outside the execution time window,the fall edge has to be written to the output channel by the set method.Moreover, when calling end method, the output signal must be fallen.

Thereby, calling end indicates to the system that the object on theother side of the channel can safely read the channel up to thespecified time because the signal will not change. The framework insuresthat this is true by blocking any writes to the channel for timesearlier than the last end call. This can cause problems in subsequentrun calls to the DUT model.

Offline DLL Interface

Next, a DLL of the module and the DUT model based on the framework isbuild and the functions that creates an instance of these models andperform any clean up after the end of the process is exported, so thatthe DLL which emulates the module of the test apparatus and the DLLwhich emulates the DUT may be created.

Supplementary information C: An example of specification of system busaccess library

C.1 Introduction

FIG. 28 shows positioning of the system bus access library 6014 in thereal environment 6000 and the emulation environment 6050. It is used incommon in the real environment 6000 of the DUT 100 and in the emulationenvironment 6050 by the test emulator 190.

FIG. 28A shows positioning of the system bus access library 6014 in thereal environment 6000 (online environment). Software 6010 is softwarewhich runs on the site controller 130 illustrated in FIG. 1. Thesoftware 6010 includes: an HLC processing section 6012 which receivesand interprets HLC (High Level Command) from the program which controlsthe test of the test apparatus 10 and generates the access command tohardware 6030; a system bus access library 6014 including acommunication library which performs communication processing based onan access command, and a bus access library which accesses a system bus(PCI bus in the present embodiment) based on instructions of thecommunication library; and a PCI bus driver 6016 which controls a systembus based on instruction of the system bus access library 6014.

The hardware 6030 includes: a bus IF 6032 included in the sitecontroller 130 illustrated in FIG. 1; the bus switch 140; and variousmodules such as the synchronous module 150, the synchronous connectionmodule 160 and/or test module 170. The bus IF 6032 connected to the busslot of the site controller 130 transmits access issued by the PCI busdriver 6016 to the modules such as the synchronous module 150 and/ortest module 170, through the bus switch 140, so that the access isprocessed.

FIG. 28B illustrates positioning of the system bus access library 6014in the emulation environment 6050 (offline environment). The offlineprocess 6060 is software which runs on the site controller 130 or thetest emulator 190 illustrated in FIG. 1, and causes the test emulator190 to act as the site control emulation section 230. The offlineprocess 6060 is a process to control the test apparatus emulationprocess 6080 instead of controlling the hardware 6030 by the software6010. The offline process 6060 provides the user of software 6010 with auser level interface in common with the software 6010 by using the HLCprocessing section 6012 and the system bus access library 6014, whichare substantially same as the software 6010. The test apparatusemulation process 6080 is a process which emulates the test apparatus10, and includes a system bus emulator 6084 which emulates the busswitch 140, and the module emulator 6086 which emulates the synchronousmodule 150, the synchronous connection module 160, and/or the testmodule 170. The system bus emulator 6084 causes the test emulator 190 toact as the bus switch emulation section 240. The module emulator 6086causes the test emulator 190 to act as the synchronous module emulationsection 250, the synchronous connection module emulation section 260,and/or the test module emulation section 270. Hereinafter, unlessotherwise specifically noted, it writes clearly, a word “module” meansat least one of the synchronous module 150, the synchronous connectionmodule 160 and the test module 170 in the online environment, and thesynchronous module emulation section 250, the synchronous connectionmodule emulation section 260 and the test module emulation section 270in the offline environment.

C.2 General Functions for Controlling the Tester Module

This chapter describes general functions used in the module driver whichruns on the site controller 130 and controls the synchronous module 150,the synchronous connection module 160, and/or the test module 170. Inthe module driver, this library is used to access registers and memoriesin the tester module and read and write the data necessary for devicemeasurement. The main functions described in this chapter are asfollows:

-   -   1. Bus access using program IO    -   2. Bus access using the DMA function    -   3. Interrupt handling    -   4. Control of library/System bus

C.2.1 Bus Access Using Program 10

There are two types of accesses to the system bus, one in which MW(Machine Word) is directly written on the register of the Tester Moduleconnected to the bus and the other in which the HLC (High Level Command)is transferred to the Tester Module. In both cases, Address and Dataflow on the system bus. If recognized as HLC by the Address on theTester Module side, the processing corresponding to the HLC is performedon the Tester Module side. For writing data from the Site CPU (the sitecontroller 130) to the Tester Module, the same data is sent to eachTester Module connected to the Site CPU and each Tester Module acquiresthe corresponding data.

FIFO is placed in the System bus and Tester Module and, therefore, ifany data is transferred from the Site CPU to the Tester Module, thewrite action of the CPU is stopped without waiting for the completion ofthe write action of the Tester Module. The time until the data isactually stored in the register is influenced by the availability ofFIFO existing between the CPU and the register of the target. Forguaranteeing that the data has definitely reached all Tester Modules,use the flush waiting function of the FIFO. When FIFOs are flushed usingthe read of the register in the Tester Module, it can be guaranteed thatonly the FIFO of the Tester Module to be read has been flushed.

In the example shown in the following diagram, if read of the registeris executed against the Tester Module 2, the read action is made to waituntil the FIFO of the Tester Module 2 is flushed, but there is noguarantee that the FIFO of the Tester Module 1 has been flushed. If thisguarantee is desired, execute reading of the Tester Module 2, using theflush waiting function of the FIFO in the Tester Module, after the FIFOof each Tester Module has been flushed.

<Offline>

No FIFO is placed in the offline System bus Emulator 6084. Therefore, ifPIO write is executed against a Module Emulator 6086 that does not haveFIFO, it returns from the function after storing data to the register ofthe Module Emulator 6086.

If any data is written in the Module Emulator 6086 having FIFO the sameas in online, the write process is immediately ended after storing datain the FIFO of the Module Emulator 6086.

2.1.1 Write Using Program IO

Write the data to the register in the Tester Module. The Site CPUterminates write operation before the written data reaches the TesterModule (posted write). [Name]   BCL_GBI_write [Syntax]   intBCL_GBI_write(unsigned int address, unsigned int data); [Argument]  address Machine word address   data Data to be written [Return value]  BCL_GBI_OK Normal termination   BCL_GBI_ERROR ErrorC.2.1.2 Read Using Program IO

Read the data in the register of the Tester Module. The Site CPU waitsuntil the data is read. Read of the target register is made to waituntil the data in the FIFO between the CPU and the target register isflushed. [Name]   BCL_GBI_read [Syntax]   int BCL_GBI_read(unsigned intaddress, unsigned int *data); [Argument]   address Machine word address  data Pointer to the variable to read the data [Return value]  BCL_GBI_OK Normal termination   BCL_GBI_ERROR ErrorC.2.1.3 Block Write Using Program IOWrite the blocks of data to the register in the Tester Module. Specifythe data format using the address and the data as a pair. The System busexecutes the write cycles for the specified number of times.

When writing data in multiple addresses, it can be executed with higherspeed than writing with the BCL_GBI_write( ) function every time. Thisis because the calling of the function is needed only once and multipleexclusions are not executed. [Name]   BCL_GBI_writeBlock [Syntax]   intBCL_GBI_writeBlock(unsigned int *address, unsigned int *data, unsignedint number); [Argument]   address Pointer to the array in which theaddress is stored   data Pointer to the array in which the data isstored [Return value]   BCL_GBI_OK Normal termination   BCL_GBI_ERRORErrorC.2.1.4 Block Read Using Program IO

Read the data in the register of the Tester Module as blocks. Theaddress of the register can be specified with discontinuous values. TheSystem bus executes the read cycles for the specified number of times.

When reading data in multiple addresses, it can be executed with higherspeed than reading with the BCL_GBI_read( ) function every time. This isbecause the calling of the function is needed only once and multipleexclusions are not executed. [Name]   BCL_GBI_readBlock [Syntax] intBCL_GBI_readBlock(unsigned int *address, unsigned int *data, unsignedint number); [Argument]   address Pointer to the array in which theaddress is stored   data Pointer to the array to read the data   numberThe number of data to be read [Return value]   BCL_GBI_OK Normaltermination   BCL_GBI_ERROR ErrorC.2.1.5 Continuous Block Write Using Program IO

The data array is written to the register placed in the evenly spacedaddresses of the Tester Module. The data array is written from thespecified starting address and the offset value is added to the addressevery time the data is written. The offset value can be specified as avalue between 0 and 0×3ffffff. The System bus executes the write cyclesfor the specified number of times.

When writing data to multiple fixed offset addresses, it can be executedwith higher speed than that of the writing using the BCL_GBI_writeBlock(). This is because of the fact that the adding of addresses is conductedby hardware and, therefore, the number of packets flowing on the PCI busbecomes smaller. [Name]   BCL_GBI_writeSeq [Syntax]   intBCL_GBI_writeSeq(unsigned int address, unsigned int *data, unsigned intnumber, unsigned int offset); [Argument]   address Machine word address  data Pointer to the array in which the data is stored   number Thenumber of data to be written   offset The offset value to be added tothe address for each data transfer. [Return value]   BCL_GBI_OK Normaltermination   BCL_GBI_ERROR ErrorC.2.1.6 Continuous Block Read Using Program IO

The data array is read from the register placed in the evenly spacedaddresses of the Tester Module. The data array is read from thespecified starting address and the offset value is added to the addressevery time the data is read. The offset value can be specified as avalue between 0 and 0×3ffffff. The System bus executes the read cyclethe specified number of times.

When reading data from multiple fixed offset addresses, it can beexecuted with higher speed than reading with the BCL_GBI_readBlock( )function every time. This is because of the fact that the adding ofaddresses is conducted by hardware and, therefore, the number of packetsflowing on the PCI bus becomes smaller. [Name]   BCL_GBI_readSeq[Syntax]   int BCL_GBI_readSeq(unsigned int address, unsigned int *data,unsigned int number, unsigned int offset); [Argument]   address Machineword address   data Pointer to the array to read the data   number Thenumber of data to be read   offset The offset value to be added to theaddress for each data transfer. [Return value]   BCL_GBI_OK Normaltermination   BCL_GBI_ERROR ErrorC.2.2 Bus Access Using DMA FunctionThe following four types of functions are available for data transferusing DMA.No. functions

-   1 Synchronous DMA write with burst/single-   2 Synchronous DMA read with burst/single-   3 Asynchronous DMA write with burst/single-   4 Asynchronous DMA read with burst/single    1. Synchronous/asynchronous DMA    In the case of synchronous DMA, the function waits for termination    of the DMA and then terminates. Although the function terminates    only after the termination of the DMA, the transferred data may    remain in the FIFO in the System bus I/F or Tester Module in certain    cases.

In the case of asynchronous DMA, the function terminates without waitingfor the DMA termination. Therefore, it is required that the lifecycle ofthe data area be guaranteed by the user. Furthermore, if any functionusing the DMA is executed before the transfer of the asynchronous DMAhas been completed, the function is forced to wait until the previousDMA transfer is completed.

The transfer ID is prepared as the identification information to waitfor the completion of asynchronous DMA processing. This transfer ID is32-bit data without a code and, if the number of DMA transfers exceeds32 bits, it returns to 0 and is reused.

2. Burst/Single DMA

In burst DMA transfer, data is transferred with packets specific toburst on the System bus. In this transfer, one address and N (64 at themaximum) data are taken as a packet and the transfer of packets isrepeated until the transfer of the specified number of data iscompleted. Therefore, high-speed transfer is possible.

In addition, in carrying out DMA transfer, the increasing value for theaddress on the Tester Module side can be specified. This increasingvalue is used to calculate the top address of the packet for transfer ofthe packet after the second group.(Address of the packet)=(Specified increasing value) (Number of data inthe preceding packet)+(Top address of the preceding packet)In addition, because the register with which burst transfer is possibledepends on the Tester Module, it is necessary to check if the registeris a usable one.

In single DMA transfer, the address and data are transferred as a set onthe System bus, the same as in program 10. Therefore, the transfer speedis lower than that for burst DMA, but transfer to any register ispossible. When conducting DMA transfer, the increasing value for theaddress on the System bus side can be specified. This increasing valueis added to the address every time an address is generated.

<Offline>

In the case of offline, even if burst transfer is specified, it istreated internally as a single transfer. Therefore, transfer to anyregister that does not support burst transfer is possible. Taking onlineuse into consideration, however, avoid any use for registers in whichburst transfer is not supported by hardware. In addition, offlinesynchronous and asynchronous DMAs are the same as those online.

C.2.2.1 Synchronous Write Using DMA Function

Transfers data placed in the memory of the Site CPU to the Tester Moduleusing DMA. This function can specify burst or single for synchronouswrite. [Name]   BCL_GBI_writeSyncDMA [Syntax]   intBCL_GBI_writeSyncDMA(unsigned int address, unsigned int *data, unsignedint number, unsigned int offset, unsigned int mode); [Argument]  address Machine word address   data Pointer to the array in which thedata is stored   number The number of data to be written   offset Theoffset value to be added to the address for each data transfer   modeBurst or single operation mode [Return value]   BCL_GBI_OK Normaltermination   BCL_GBI_ERROR ErrorC.2.2.2 Synchronous Read Using I)MA Function

Data using the DMA from the register in the Tester Module is read to thememory of the Site CPU. This function can specify burst or single forsynchronous read. [Name]   BCL_GBI_readSyncDMA [Syntax]   intBCL_GBI_readSyncDMA(unsigned int address, unsigned int *data, unsignedint number,   unsigned int offset, unsigned int mode); [Argument]  address Machine word address   data Pointer to the array to read thedata   number The number of data to be read   offset The offset value tobe added to the address for each data transfer   mode Burst or singleoperation mode [Return value] BCL_GBI_OK Normal terminationBCL_GBI_ERROR ErrorC.2.2.3 Asynchronous Write Using DMA Function

The data placed in the memory of the Site CPU is transferred to theTester Module using DMA. This function can specify burst or single forasynchronous write. [Name]   BCL_GBI_writeAsyncDMA [Syntax]   intBCL_GBI_writeSyncDMA(unsigned int address, unsigned int *data, unsignedint number,   unsigned int offset, unsigned int mode, unsigned int*transferID); [Argument]   address Machine word address   data Pointerto the array in which the data is stored   number The number of data tobe written   offset The offset value to be added to the address for eachdata transfer   mode Burst or single operation mode   transferID Pointerfor ID for waiting for completion of transfer [Return value]  BCL_GBI_OK Normal termination   BCL_GBI_ERROR ErrorC.2.2.4 Asynchronous Read Using DMA Function

Data using the DMA from the register in the Tester Module is read to thememory of the Site CPU. This function can specify burst or single forasynchronous read. [Name]   BCL_GBI_readAsyncDMA [Syntax]   intBCL_GBI_readAsyncDMA(unsigned int address, unsigned int *data, unsignedint number,   unsigned int offset, unsigned int mode, unsigned int*transferID); [Argument]   address Machine word address   data Pointerto the array to read the data   number The number of data to be read  offset The offset value to be added to the address for each datatransfer   mode Burst or single operation mode   transferID Pointer forID for waiting for completion of transfer [Return value]   BCL_GBI_OKNormal termination   BCL_GBI_ERROR ErrorC.2.2.5 Waiting for Completion of Asynchronous DMA Transfer

Waits for the completion of transfer in asynchronous transfer using theDMA. This function terminates when the DMA is completed or the specifiedtime has elapsed. Because the resolution uses 1 ms 32-bit signed timer,the range for time specification is 0-(INT_MAX/1000). If anyspecification is made outside this range, it is treated the same as whenBCL_GBI_INFINITE is specified.

In transferID is specified with a wrong value, BCL_GBI_OK is returnedimmediately and this function is terminated. [Name]   BCL_GBI_waitDMA[Syntax]   int BCL_GBI_waitDMA(unsigined int transferID, doubletimeOut); [Argument]   transferID ID waiting for completion of transferreturned in asynchronous mode transfer   timeOut Waiting time >= 0 :timeout period [s] BCL_GBI_INFINITE : waits until the DMA terminates.[Return value]   BCL_GBI_OK DMA terminates normally.   BCL_GBI_TIMEOUTTimeout   BCL_GBI_ERROR The DMA terminates abnormally.C.2.2.6 Status of Asynchronous DMA Transfer

Gives notice of the current status of asynchronous DMA transfer. If awrong transferID is specified, gives notice of the same status as thetermination of the DMA. [Name]   BCL_GBI_getConditionDMA [Syntax]   intBCL_GBI_getConditionDMA(unsigned int transferID); [Argument]  transferID ID waiting for completion of transfer returned inasynchronous mode transfer [Return value]   BCL_GBI_BUSY DMA beingexecuted   BCL_GBI_OK DMA terminates normally.   BCL_GBI_ERROR DMAterminates abnormally.C.2.3 Interrupt Handling

In the System bus access library, functions for carrying out basicinterrupt operation are provided. There are four types of interruptsoperable using the System bus access library.

-   -   1. Bus error interrupt (only for online)        -   Up to 65 interrupt handlers can be registered.    -   2. Bus timeout interrupt        -   Up to 65 interrupt handlers can be registered.    -   3. Sync error interrupt (only for online)        -   Up to 65 interrupt handlers can be registered.    -   4. Interrupt generated from the Tester Module        -   Up to 2 interrupt handlers can be registered with each bus            number.

It is executed with interrupt thread together with above-mentionedinterrupt. Bus error, Bus timeout or Sync error interrupt generated bythe System bus I/F disables the interrupt inside the interrupt threadand then executes the interrupt handlers of the registered target inturns. After execution of the target interrupt handlers is completed,the interrupt thread clears the factor of the interrupt and enables theinterrupt internally.

For acceptance of interrupt, control of enable/disable can be controlledby the function of this library separately from enable/disable insidethe interrupt thread. For the interrupt generated in the Tester Module,the interrupt thread disables the interrupt internally and executes thelock of the interrupt for the Tester Module. Then, interrupt handlerscorresponding to the bus number causing the interrupt are executed byturns. After completing the execution of the target interrupt handlers,the interrupt thread clears the factor of the interrupt for the TesterModule. Then the lock of the interrupt is released and the interrupt isenabled internally.

For acceptance of interrupt, control of enable/disable can be controlledby the function of this library separately from enable/disable insidethe interrupt thread. Inhibition/permission for interrupt can becontrolled both on the System bus board and the Tester Module.

Inhibition/permission on the System bus I/F side simply enables/disablesthe interrupt from the Tester Module. Lock/unlock of interrupt on theTester Module side controls generation of interrupt on the source ofinterrupt on the Tester Module side. During lock, generation of newinterrupt in the Tester Module is inhibited and change in the statusrelated to interrupt is also inhibited. After unlock, generation ofinterrupt on the Tester Module side becomes possible.

C.2.3.1 Registration of Module Interrupt Handler

The interrupt handler function at the time of occurrence of theinterrupt from the Tester Module is registered. When an interrupt hasoccurred, the registered function is executed with the exclusive threadfor the interrupt handler. The interrupt handler is registered togetherwith the bus number, and the interrupt handler that has the sameregistered bus number as that of the Tester Module that reported theinterrupt is activated.

In addition, the value set at the time of registration is returned tothe interrupt handler. Two interrupt handlers can be registered at thesame time for each bus number. Bus numbers can be specified from 1 to64. If successfully registered, the key number is returned as the returnvalue. If registration is carried out using this key number, there-registration and deletion of the interrupt handler with this keynumber becomes possible. If any registration is carried out byspecifying 0 as the key number, the interrupt handler will be set to avacant key number. If there is no vacant key number, an error occurs and(−1) will be returned as the return value. With respect to execution ofinterrupt handlers in the case in which two interrupt handlers have beenregistered, the execution is carried out from the younger key number.

Deletion of the interrupt handler is registered by setting the addressof the callback function to BCL_GBI_IGNORE_MODULE_HANDLER. The interruptthread does not execute the interrupt handler ofBCL_GBI_IGNORE_MODULE_HANDLER.If both of two interrupt handlers for eachbus number become BCL_GBI_IGNORE_MODULE_HANDLER, interrupt handlers ofthat bus number return to the default. (The standard interrupt handlerin the access library will be set.) [Name]   BCL_GBI_addInterruptHandler[Syntax]   int BCL_GBI_addInterruptHandler(unsigned int BusNo, intKeyNo,     BCL_GBI_MODULE_HANDLER handler, unsigned int arg); [call backfunction]   void InterruptRoutine(unsigned int BusNo, unsigned intFactor, unsigned int arg); [Argument]   BusNo Bus number   KeyNo Keynumber   handler Call back function address   arg Value to be given tointerrupt handler   Factor interrupt factor (dependent on each module)[Return value]   Key number to which interrupt handler is registered  If it is (−1), registration failed (invalid bus number or key number).C.2.3.2 Registration of Bus Error Interrupt Handler

The error processing function for the case in which error occurred inthe System bus is registered. If any error occurs in the System bus, theinterrupt thread executes the registered function. In addition, if anyerror occurs in the System bus, the interrupt is cleared by theinterrupt thread. It is not necessary to clear inside the interrupthandler.

Up to 65 interrupt handlers for Bus error can be registered. Ifsuccessfully registered, the key number is returned as the return value.If registration is carried out using this key number, there-registration and deletion of the interrupt handler with this keynumber becomes possible. If any registration is carried out byspecifying 0 as the key number, the interrupt handler will be set to avacant key number. If there is no vacant key number, an error occurs and(−1) will be returned as the return value. Deletion of the interrupthandler is registered by setting the address of the callback function toBCL_GBI_IGNORE_BUSERROR_HANDLER.

The interrupt thread does not execute the interrupt handler ofBCL_GBI_IGNORE_BUSERROR_HANDLER. If all 65 interrupt handlers becomeBCL_GBI_IGNORE_BUSERROR_HANDLER, they return to the default. (Thestandard interrupt handler in the access library will be set.) Bus errormay occur due to an error in communication of the System bus or failedhardware.

<Offline>

Because there is no factor to cause any error in the Bus offline, thehandler registered with this function does not function. [Name]  BCL_GBI_addBusErrorInterruptHandler [Syntax]   intBCL_GBI_addBusErrorInterruptHandler(int KeyNo,    BCL_GBI_MODULE_HANDLER handler, unsigned int arg); [call backfunction]   void BusErrorInterruptRoutine(unsigned int arg); [Argument]  KeyNo Key number   handler Call back function address   arg Value tobe given to interrupt handler [Return value]   Key number to whichinterrupt handler is registered   If it is (−1), registration failed(invalid bus number or key number).2.3.3 Registration of Bus Timeout Interrupt Handler

The error processing function for the case in which timeout occurs inthe System bus is registered. If any timeout occurs in the System bus,the interrupt thread executes the registered function. In addition, ifany timeout occurs in the System bus, the interrupt is cleared by theinterrupt thread.

It is not necessary to clear inside the interrupt handler. Up to 65interrupt handlers for Bus timeout can be registered. If successfullyregistered, the key number is returned as the return value. Ifregistration is carried out using this key number, the re-registrationand deletion of the interrupt handler with this key number becomespossible. If any registration is carried out by specifying 0 as the keynumber, the interrupt handler will be set to a vacant key number. Ifthere is no vacant key number, an error occurs and (−1) will be returnedas the return value. Deletion of the interrupt handler is registered bysetting the address of the callback function toBCL_GBI_IGNORE_TIMEOUT_HANDLER.

The interrupt thread does not execute the interrupt handler ofBCL_GBI_IGNORE_TIMEOUT_HANDLER. If all 65 interrupt handlers becomeBCL_GBI_IGNORE_TIMEOUT_HANDLER, they return to the default. (Thestandard interrupt handler in the access library will be set.) Bustimeout occurs at the time of read in the condition in which a cable isdisconnected or the receiver does not exist. Failed hardware can also bethe cause.

[Name]

-   -   BCL_GBI_addTimeoutInterruptHandler        [Syntax]    -   int BCL_GBI_addTimeoutInterruptHandler(int KeyNo,        -   BCL_GBI_TIMEOUT_HANDLER handler, unsigned int arg);            [call back function]    -   void TimeoutInterruptRoutine(unsigned int address, unsigned int        Factor, unsigned int arg);        [Argument]    -   KeyNo Key number    -   handler Call back function address    -   address Machine work address when a timeout has occurred    -   Factor Factor that caused the timeout        BCL_GBI_FACTOR_MODULE Read of Tester Module        BCL_GBI_FACTOR_CONFIG Read of configuration data        BCL_GBI_FACTOR_WRITE All write operations    -   arg Value to be given to interrupt handler        [Return Value]    -   Key number to which interrupt handler is registered    -   If it is (−1), registration failed (invalid bus number or key        number).        C.2.3.4 Registration of Sync Error Interrupt Handler

The error processing function for the case in which Sync error occurredin the System bus is registered. If any Sync error occurs in the Systembus, the interrupt thread executes the registered function. In addition,if any Sync error occurs in the System bus, the interrupt is cleared bythe interrupt thread. It is not necessary to clear inside the interrupthandler.

Up to 65 Interrupt handlers for Sync error can be registered. Ifsuccessfully registered, the key number is returned as the return value.If registration is carried out using this key number, there-registration and deletion of the interrupt handler with this keynumber becomes possible. If any registration is carried out byspecifying 0 as the key number, the interrupt handler will be set to avacant key number. If there is no vacant key number, an error occurs and(−1) will be returned as the return value.

Deletion of the interrupt handler is registered by setting the addressof the callback function to BCL_GBI_IGNORE_SYNCERROR_HANDLER. Theinterrupt thread does not execute the interrupt handler ofBCL_GBI_IGNORE_SYNCERROR_HANDLER. If all 65 interrupt handlers becomeBCL_GBI_IGNORE_SYNCERROR_HANDLER, they return to the default. (Thestandard interrupt handler in the access library will be set.)

Sync error may be caused by improper setting of software or faultydesign of hardware. Failed hardware can also be the cause.

<Offline>

Because there is no factor to cause any Sync error in the Bus offline,the handler registered with this function does not function.

[Name]

-   -   BCL_GBI_addSyncErrorInterruptHandler        [Syntax]    -   int BCL_GBI_addSyncErrorInterruptHandler(int KeyNo,        -   BCL_GBI_SYNCERROR_HANDLER handler, unsigned int arg);            [call back function]    -   void SyncErrorInterruptRoutine(unsigned int arg);        [Argument]    -   KeyNo Key number    -   handler Call back function address    -   arg Value to be given to interrupt handler        [Return Value]    -   Key number to which interrupt handler is registered    -   If it is (−1), registration failed (invalid bus number or key        number).        C.2.4 Control of Library/System bus        C.2.4.1 FIFO Flush Wait

Flush of FIFO in all Tester Modules connected to the System bus that isconnected to the Site CPU is waited for. FIFOs exist in the System busI/F board and Tester Module. If this function is terminated, it meansthat all the data that existed in the FIFO immediately before executingthis function are written to the Tester Module. Because the CPU issues aread cycle to the PCI bus during execution of this function, the bus islocked by hardware until the FIFO is flushed. Therefore, a delay mayoccur in DMA transfer, interrupt acceptance, etc. Furthermore, incertain cases, timeout may occur because of execution of this function.Furthermore, in certain cases, timeout may occur because of execution ofthis function.

<Offline>

Offline, FIFO of System bus I/F Emulator does not exist. In addition,the existence of FIFO in the Tester Module is vendor-dependent.

[Name]

-   -   BCL_GBI_waitFlushFIFO        [Syntax]    -   int BCL_GBI_waitFlushFIFO(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Flush completed    -   BCL_GBI_ERROR Error        C.2.4.2 Resetting Module

Tester Modules connected to the Site CPU are reset. In this function,the following processing is conducted.

-   1. Sending out the bus reset packet to the System bus-   2. Sending out the packet to clear the interrupt to the System bus-   3. Sending out the unlock packet for the interrupt to the System bus

The resetting action and the time needed depend on each Tester Module.

[Name]

-   -   BCL_GBI_resetModule        [Syntax]    -   int BCL_GBI_resetModule(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.2.4.3 Initializing the Library

The System bus access library is initialized. When using the System busaccess library, it is necessary to carry out this initialization atfirst. In this function, the following processes are executed.

-   1. Initialization of the variable of the access library-   2. Activation of the thread for executing the interrupt handler The    interrupt on the System bus I/F is in disabled status.    <Offline>    In the case of offline, inter-process communication with the System    bus Emulator is prepared by this function. A timeout occurs if the    connection with the System bus Emulator is not established within 30    seconds.    [Name]    -   BCL_GBI_init        [Syntax]    -   int BCL_GBI_init(unsigned int siteNo, int mode);        [Argument]    -   siteNo Site number (1 to 8)    -   mode Specifying Online/Offline        -   BCL_GBI_ONLINE Online        -   BCL_GBI_OFFLINE Offline            [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR The site number is out of definition.    -   <Offline>    -   BCL_GBI_TIMEOUT Cannot connect with the System bus Emulator        within 30 seconds        C.2.4.4 Releasing the Library

Process for ending the use of the System bus access library is carriedout.

[Name]

-   -   BCL_GBI_finish        [Syntax]    -   int BCL_GBI_finish(unsigned int siteNo); 130        [Argument]    -   siteNo Site number (1 to 8)130        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR The site number is out of definition.        C.2.4.5 Determining Online/Offline

Determine whether the currently run System bus access library isoperating online or offline.

[Name]

-   -   BCL_GBI_isOnline        [Syntax]    -   int BCL_GBI_isOnline(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_ONLINE Online    -   BCL_GBI_OFFLINE Offline        C.2.4.6 Verifying the Connection with the GBSC

Verifies whether or not the System bus I/F can be connected with theGBSC.

This can also verify whether or not the GBSC is turned on.

[Name]

-   -   BCL_GBI_getConnected        [Syntax]    -   int BCL_GBI_getConnected(unsigned int *connect);        [Argument]    -   connect Pointer to the variable to store the result of whether        or not the System bus I/F can be connected with the GBSC        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.2.4.7 Acquiring Detailed Error Information

Returns detailed information of the error which occurred when the Systembus access library returned BCL_GBI_ERROR.

[Name]

-   -   BCL_GBI_getLastError        [Syntax]    -   unsigned int BCL_GBI_getLastError(void);        [Argument]    -   None        [Return Value]    -   Returns unsigned 32-bit error information.    -   bit31 Value to identify the error code type.        -   0: Windows error code (refer to System Error Codes)        -   1: Access library unique error code    -   bit30-24 Value to identify where the error occurred in the        function        (internal information)    -   bit23-16 Value to identify the access library function where the        error occurred    -   bit15-0 Error code    -   When bit31 is 0: Lower 16-bit value of GetLastError( )    -   When bit31 is 1: Access library internal error value        C.2.4.8 Acquiring Detailed Error Information History

Returns detailed information of the last 16 errors (maximum) whichoccurred when the System bus access libraries returned BCL_GBI_ERROR.

[Name]

-   -   BCL_GBI_getPreviousErrors        [Syntax]    -   unsigned int BCL_GBI_getPreviousErrors(unsigned int *error,        unsigned int size);        [Argument]    -   error Pointer to the array variable to store error information

The error information format is the same as BCL_GBI_getLastError( ).

-   -   size Size of the array variable to store the error information        [Return Value]

The number of stored error information units is returned.

C.3 Timer Functions

This chapter describes the functions which control the timer hardware onthe System bus I/F board.

The resolution of the timer hardware on the System bus I/F board is 1[us].

3.1 Reading the Elapsed Time

3.1.1 Reading the Time

The elapsed time after the System bus access library is initialized canbe read in seconds [s].

<Restrictions>

The resolution is 1 [us]. However, if the read value is larger than thesignificant digits of double * 1 [us], a resolution of 1 [us] may not beobtained because data is converted to double type and then read. Thesignificant digits of double are 15 digits in decimal, therefore,theoretically, a resolution of 1 [us] cannot be obtained for about 31years from initialization.

The hardware counter operates in 64 bits, therefore, theoretically, itwill return to 0 after about 580,000 years after the System bus accesslibrary is initialized. In the program, the difference (elapsed time)between readings at regular intervals may not be the same due to theload conditions of the CPU or PCI bus, or due to the FIFO conditions.

<Offline>

When offline, the elapsed time, from when the SiteCPU is started, isread in seconds [s].

[Name]

-   -   BCL_TMR_readTime        [Syntax]    -   int BCL_TMR_readTime(double *time);        [Argument]    -   time Elapsed time [s] after the initialization of the System bus        access library        [Return Value]    -   BCL_TMR_OK Normal termination        C.3.1.2 Reading the Timer Counter

The elapsed time after initializing the System bus access library isinitialized can be read in count value. The count value increases by 1with an elapse of 1 [us].

<Restrictions>

The hardware counter operates in 64 bits, therefore, theoretically, itwill return to 0 after about 580,000 years after the System bus accesslibrary is initialized. In the program, the difference (elapsed time)between readings at regular intervals may not be the same due to theload conditions of the CPU or PCI bus, or due to the FIFO conditions.

<Offline>

When offline, the elapsed time, from when the SiteCPU is started, isread as the count value.

[Name]

-   -   BCL_TMR_readCount        [Syntax]    -   int BCL_TMR_readCount(unsigned_int64 *count);        [Argument]    -   count The count value after initialization of the System bus        access library (1 [us]/1 count)        [Return Value]    -   BCL_TMR_OK Normal termination        C.3.2 Wait Functions        C.3.2.1 Wait Time

This function causes the next function to wait until the specified timeelapses. If a value smaller than 1 [us] is specified as the wait time,the next function will start immediately.

<Restrictions>

The wait time may be longer than the specified time, depending on theload conditions of the CPU.

<Offline>

When offline, the wait time is based on the value in which less than 1[ms] is rounded off. For example, if a value smaller than 1 [ms] isspecified as the wait time (time), the function will be returnedimmediately. The maximum wait time is 4294967.296 [s] (approximately 49days).

[Name]

-   -   BCL_TMR_wait        [Syntax]    -   int BCL_TMR_wait(double time);        [Argument]    -   time Wait time specified in seconds [s]        [Return Value]    -   BCL_TMR_OK Normal termination    -   BCL_TMR_ERROR Wait cancelled        C.3.2.2 Cancelling the Wait Function

All processes of the currently run BCL_TMR_wait function can becancelled. When the function is executed in multiple threads, all theprocesses of BCL_TMR_wait function are cancelled.

[Name]

-   -   BCL_TMR_cancel        [Syntax]    -   int BCL_TMR_cancel(void);        [Argument]    -   None        [Return Value]    -   BCL_TMR_OK Normal termination        C.4 Functions Specifically for Configuration/Diagnostics

This chapter describes the functions used for hardware configuration andhardware diagnostics. If used for any purpose other than hardwareconfiguration and hardware diagnosis, data transfer to the tester moduleor interruption operation cannot be performed properly. Use thesefunctions for hardware configuration and hardware diagnosis afterlearning the hardware structures of System bus I/F board, bus switch andtester module, etc.

No runtime error occurs in this library during operation, but, if usedin any function other than bus configuration and hardware diagnosis,functions of this library and the System bus I/F board with respect tointerruption of the device driver are not guaranteed.

C.4.1 Configuration Control (Special Function)

The function described in this chapter is a function used forconfiguration of System bus I/F and the tester module. Because datatransfer to the tester module becomes impossible if carelessly operated,use it after becoming thoroughly familiar with the structure of thehardware and software.

C.4.1.1 Bus Configuration Write

Data is written to the System bus I/F and Tester Module configurationregister. This function is terminated after the configuration data isstored in the System bus I/F and the Tester Module.

[Name]

-   -   BCL_GBI_writeBusConfig        [Syntax]    -   int BCL_GBI_writeBusConfig(unsigned int address, unsigned int        config);        [Argument]    -   address Configuration data address    -   config Configuration data to be written        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.1.2 Bus Configuration Read    -   Data are read from the System bus I/F and Tester Module        configuration register.        [Name]    -   BCL_GBI_readBusConfig        [Syntax]    -   int BCL_GBI_readBusConfig(unsigned int address, unsigned int        *config);        [Argument]    -   address Configuration data address    -   config Pointer to the variable to store configuration data        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.1.3 Completing the Bus Switch Configuration Setting

When online, nothing is executed.

<Offline>

Offline bus connection can be switched by executing this function whenbus switch configuration write is complete.

[Name]

-   -   BCL_GBI_decideBusMatrix        [Syntax]    -   int BCL_GBI_decideBusMatrix (void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2 Interrupt control (Special function)

The function described in this chapter is a function used for busconfiguration and hardware diagnostics. Because interruption of theSystem bus I/F board is directly controlled, if operated carelessly, thedevice driver of the System bus I/F board and this library cannotexecute interrupt processing.

C.4.2.1 Bus I/F Board Interrupt Enable

Various interrupt signals are enabled on the System bus I/F board. Thereare four types of interrupt signals: interrupt from the Tester Module,Bus error, Bus timeout and Sync error. Those signals can be set as thebit information defined as follows. In specifying multiple interruptsignals, set them as logical OR. This function terminates after makingsure that the interrupt has been enabled on the System bus I/F.

[Name]

-   -   BCL_GBI_interruptEnable        [Syntax]    -   int BCL_GBI_interruptEnable(unsigned int status);        [Argument]    -   status Interrupt signal specification        -   BCL_GBI_INT_MODULE Interrupt from the Tester Module        -   BCL_GBI_INT_BUSERROR Bus error        -   BCL_GBI_INT_TIMEOUT Bus timeout        -   BCL_GBI_INT_SYNCERROR Sync error            [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2.2 Bus I/F Board Interrupt Disable

Various interrupt signals are disabled on the System bus I/F board.There are four types of interrupt signals: interrupt from the TesterModule, Bus error, Bus timeout and Sync error. Those signals can be setas the bit information defined as follows. In specifying multipleinterrupt signals, set them as logical OR. This function terminatesafter making sure that the interrupt has been disabled on the System busI/F.

[Name]

-   -   BCL_GBI_interruptDisable        [Syntax]    -   int BCL_GBI_interruptDisable(unsigned int status);        [Argument]    -   status Interrupt signal specification        -   BCL_GBI_INT_MODULE Interrupt from the Tester Module        -   BCL_GBI_INT_BUSERROR Bus error        -   BCL_GBI_INT_TIMEOUT Bus timeout        -   BCL_GBI_INT_SYNCERROR Sync error            [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2.3 Bus I/F Board Interrupt Read

Various interrupt signals are read on the System bus I/F board. Thereare four types of interrupt signals: interrupt from the Tester Module,Bus error, Bus timeout and Sync error. Those signals can be read as thebit information defined as follows:

[Name]

-   -   BCL_GBI_interruptRead        [Syntax]    -   int BCL_GBI_interruptRead(unsigned int *status);        [Argument]    -   status Pointer to the variable to read the interrupt signal        -   BCL_GBI_INT_MODULE Interrupt from the Tester Module        -   BCL_GBI_INT_BUSERROR Bus error        -   BCL_GBI_INT_TIMEOUT Bus timeout        -   BCL_GBI_INT_SYNCERROR Sync error            [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2.4 Bus I/F Board Interrupt Clear

Various interrupt signals are cleared on the System bus I/F board. Thereare four types of interrupt signals: interrupt from the Tester Module,Bus error, Bus timeout and Sync error. Those signals can be set as thebit information defined as follows. In specifying multiple interruptsignals, set them as logical OR. This function clears the interrupt onthe System bus I/F after the FIFO of each Tester Module immediatelybefore this function was executed has been flushed. This functionterminates after making sure that the interrupt has been cleared on theSystem bus I/F.

When only the interrupt from Tester Module (BCL_GBI_INT_MODULE) isspecified, flush the FIFO of each of the Tester Modules just beforeexecuting this function, clear the interrupt on the System bus I/F,confirm that the interrupt on the System bus I/F is cleared, and end theprocess.

[Name]

-   -   BCL_GBI_interruptClear        [Syntax]    -   int BCL_GBI_interruptClear(unsigned int status);        [Argument]    -   status Interrupt signal specification        -   BCL_GBI_INT_MODULE Interrupt from the Tester Module        -   BCL_GBI_INT_BUSERROR Bus error        -   BCL_GBI_INT_TIMEOUT Bus timeout        -   BCL_GBI_INT_SYNCERROR Sync error            [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2.5 Setting Number of Modules to Be Synchronized

The number of all Tester Modules connected to the System bus that isconnected to the Site CPU is set on the System bus I/F board. With thissetting, the number of modules to synchronize FIFO is determined.

<Offline>

Offline, FIFO of System bus I/F Emulator does not exist.In addition, theexistence of FIFO in the Tester Module is vendor-dependent.

[Name]

-   -   BCL_GBI_setSyncCount        [Syntax]    -   int BCL_GBI_setSyncCount(unsigned int number);        [Argument]    -   number Number of modules to be synchronized        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2.6 Saving Interrupt Settings

The interrupt signal setting (enable or disable) on the System bus I/Fboard and the interrupt occurrence setting (lock or unlock) from theTester Module are saved. This function is used to save the currentsettings before interrupt is executed in diagnosis or other operations.The saved settings are restored by using theBCL_GBI_restoreInterruptCondition( ) function. If this function isexecuted more than once, the previously saved settings are deleted andonly the most recently saved settings take effect.

<Offline>

When offline, this feature is invalid and nothing happens in thisfunction.

[Name]

-   -   BCL_GBI_saveInterruptCondition        [Syntax]    -   int BCL_GBI_saveInterruptCondition(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2.7 Restoring Interrupt Settings

The interrupt signal setting (enable or disable) on the System bus I/Fboard and the interrupt occurrence setting (lock or unlock) from theTester Module saved by using the BCL_GBI_saveInterruptCondition( )function are restored. After the interrupt is executed in diagnosis orother operations, this function is used to restore the settings beforethe operation. If this function is executed without using theBCL_GBI_saveInterruptCondition( ) function to save the settings, thefunction returns an error. If this function is executed more than once,no error occurs and the most recently saved settings are restored.

<Offline>

When offline, this feature is invalid and nothing happens in thisfunction.

[Name]

-   -   BCL_GBI_restoreInterruptCondition        [Syntax]    -   int BCL_GBI_restoreInterruptCondition(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.4.2.8 Reading Module Interrupt Factors

The factors and the number of factors, when the interrupt from theTester Module occurs, are read. A maximum of 256 (4 bytes per factor)interrupt factors exist. Among these, only factors where interruptsoccurred are returned. Consider the maximum number of factors whereinterrupts can occur (256 unsigned int type) and allocate sufficientnumber of buffers to read the factors.

<Offline>

When offline, this feature is invalid and nothing happens in thisfunction.

[Name]

-   -   BCL_GBI_readInterruptFactor        [Syntax]    -   int BCL_GBI_readInterruptFactor(unsigned int *Factor, int        *number);        [Argument]    -   Factor Pointer to the array to read the interrupt factors    -   number Pointer to the array to store the number of interrupt        factors        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.5 PENDING FUNCTIONS        Pending functions        5.1.1 Cancellation of Asynchronous DMA Transfer (Non-disclosure)

Cancels the asynchronous DMA transfer being executed. Synchronous DMAcannot be cancelled. If a wrong transferID is specified, cancellation ofthe DMA is not executed and the status of normal termination returns.

[Name]

-   -   BCL_GBI_cancelDMA        [Syntax]    -   int BCL_GBI_cancelDMA(unsigned int transferID);        [Argument]    -   transferID ID waiting for completion of transfer returned in        asynchronous mode transfer        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.5.1.2 Acquisition of PCI Base Address (Non-disclosure)

The base address of the PCI bus, which is used in the System bus I/Fboard, can be acquired. This function is used in the diagnostic processfor the System bus I/F board, etc. This address can be used only for aprocess from which the address has been acquired. If the acquiredaddress is NULL, the library has not been initialized. Initialize thelibrary by using the BCL_GBI_init function and then use this function.

<Note>

This function is used only in the debugging process and cannot be usedfor any products in any way.

<Offline>

When offline, this feature is invalid and nothing happens in thisfunction.

[Name]

-   -   BCL_GBI_exportPciBaseAddress        [Syntax]    -   PULONG BCL_GBI_exportPciBaseAddress(void);        [Argument]    -   None        [Return Value]    -   NULL Error    -   Not NULL PCI base address of System bus I/F        C.5.1.3 Tester Module Interrupt Lock (Non-disclosure)

Occurrences of interrupts from the Tester Module can be disabled at thesource of the interrupts. After setting the interrupt lock, no interruptis issued from the Tester Module. This function ends after the lockcommand is completely stored in each of the Tester Modules.

[Name]

-   -   BCL_GBI_interruptLock        [Syntax]    -   int BCL_GBI_interruptLock(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.5.1.4 Tester Module Interrupt Unlock (Non-disclosure)

Occurrences of interrupts from the Tester Module can be enabled at thesource of the interrupts. Executing this function allows the TesterModule to issue interrupts that have been suspended by the interruptlock function or interrupts which are generated after unlocking.

This function ends after the unlock command is completely stored in eachof the Tester Modules.

[Name]

-   -   BCL_GBI_interruptUnlock        [Syntax]    -   int BCL_GBI_interruptUnlock(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.5.1.5 Outputting Detailed Error Information (Non-disclosure)

Outputs the detailed information of the error, which occurred when theSystem bus access library returned BCL_GBI_ERROR, to the standard outputstream.

[Name]

-   -   BCL_GBI_printLastError        [Syntax]    -   void BCL_GBI_printLastError(void);        [Argument]    -   None        [Return Value]    -   None        C.5.1.6 Outputting the Detailed Error Information History        (Non-disclosure)

Outputs the detailed information of the last 16 errors (maximum), whichoccurred when the System bus access libraries returned BCL_GBI_ERROR, tothe standard output stream.

[Name]

-   -   BCL_GBI_printPreviousErrors        [Syntax]    -   void BCL_GBI_printPreviousErrors(void);        [Argument]    -   None        [Return Value]    -   None        C.5.1.7 Debug Mode Control (Non-disclosure)

Controls the debug mode implemented for the access library.

[Name]

-   -   BCL_GBI_verbose        [Syntax]    -   void BCL_GBI_verbose(int val);        [Argument]    -   val Debug mode specification        [Return Value]    -   None        C.5.1.8 Trace Function Enable (Non-disclosure)

Enables the trace function of the access library. When the tracefunction is enabled, it becomes possible to trace the bus access and thefunctions. The bus access tracing allows the accessed address and dataand read/write identification to be indicated in the standard outputstream. The function tracing allows the executed function names to beindicated in the standard output stream. Any function can be registeredas a function that executes tracing and replaced for a previouslyregistered function.

The access library contains the following functions that execute busaccess tracing:

-   BCL_GBI_write-   BCL_GBI_read-   BCL_GBI_writeBlock-   BCL_GBI_readBlock-   BCL_GBI_writeSeq-   BCL_GBI_readSeq-   BCL_GBI_writeSyncDMA-   BCL_GBI_readSyncDMA-   BCL_GBI_writeAsyncDMA-   BCL_GBI_readAsyncDMA-   BCL_GBI_writeConfig-   BCL_GBI_readConfig    The access library contains the following functions that execute    function tracing:-   BCL_GBI_waitFlushFIFO-   BCL_GBI_waitDMA-   BCL_GBI_cancelDMA-   BCL_GBI_conditionDMA-   BCL_GBI_syncCount-   BCL_GBI_resetModule    [Name]    -   BCL_GBI_ioTraceEnable        [Syntax]    -   int BCL_GBI_ioTraceEnable(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.5.1.9 Trace Function Disable (Non-disclosure)

Disables the trace function of the access library. When the tracefunction is disabled, it becomes impossible to trace the bus access andthe functions.

[Name]

-   -   BCL_GBI_ioTraceDisable        [Syntax]    -   int BCL_GBI_ioTraceDisable(void);        [Argument]    -   None        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.5.1.10 Address Filter Specification for the Trace Function        (Non-disclosure)

Specifies the address filter for bus access tracing. A single address orcontinuous addresses can be specified for filtering, depending on thefilter mode. Up to 16 address specifications are allowed. When the tracefunction is enabled, only the addresses that match any of the addressspecifications are traced.

[Name]

-   -   BCL_GBI_ioTraceAddress        [Syntax]    -   int BCL_GBI_ioTraceAddress(int mode, . . . );    -   int BCL_GBI_ioTraceAddress(0);    -   int BCL_GBI_ioTraceAddress(1, addr);    -   int BCL_GBI_ioTraceAddress(2, start_addr, stop_addr);        [Argument]    -   mode Specifies any of the following filter modes:        -   0: Filter specification is cancelled.        -   1: Single address specification        -   2: Continuous address specification    -   addr Target address at the time of single address specification    -   start_addr Start address at the time of continuous address        specification    -   stop_addr End address at the time of continuous address        specification        [Return Value]    -   BCL_GBI_OK Normal termination    -   BCL_GBI_ERROR Error        C.5.1.11 Output of Information Set for the Trace Function        (Non-disclosure)

Outputs the information currently set for the trace function to thestandard output stream. Use this function to check whether the tracefunction is enabled or disabled or to check the settings of the addressfilter.

[Name]

-   -   BCL_GBI_ioTraceShow        [Syntax]    -   int BCL_GBI_ioTraceShow(void);        [Argument]    -   None        [Return Value]    -   None        C.5.1.12 Simplified Help Information Output for the Trace        Function (Non-disclosure)

Outputs the simplified help information of the trace function to thestandard output stream.

[Name]

-   -   BCL_GBI_ioTraceHelp        [Syntax]    -   int BCL_GBI_ioTraceHelp(void);        [Argument]    -   None        [Return Value]    -   None        C.5.1.13 Trace Function Registration (Non-disclosure)

Replaces a default trace function that executes the tracing with anothertrace function. When the trace function is enabled, the registered tracefunction is executed from the access library function to be tracedimmediately after registration. Only one function can be registered. Ifan attempt is made to register a function when one is alreadyregistered, the previously registered function is overwritten. Executethe BCL_GBI_ioTraceResetHandler function to reset the trace function tothe default.

The access library contains the following functions that executetracing:

-   BCL_GBI_write-   BCL_GBI_read-   BCL_GBI_writeBlock-   BCL_GBI_readBlock-   BCL_GBI_writeSeq-   BCL_GBI_readSeq-   BCL_GBI_writeSyncDMA-   BCL_GBI_readSyncDMA-   BCL_GBI_writeAsyncDMA-   BCL_GBI_readAsyncDMA-   BCL_GBI_writeConfig-   BCL_GBI_readConfig-   BCL_GBI_waitFlushFIFO-   BCL_GBI_waitDMA-   BCL_GBI_cancelDMA-   BCL_GBI_conditionDMA-   BCL_GBI_syncCount-   BCL_GBI_resetModule    [Name]    -   BCL_GBI_ioTraceHandler        [Syntax]    -   void BCL_GBI_ioTraceHandler(BCL_GBI_TRACE_HANDLER handler, void        *arg);        [Argument]    -   handler Call back function address    -   arg Value to be given to trace handler        [Return Value]    -   None        C.5.1.14 Default Trace Function Registration (Non-disclosure)

Resets a trace function replaced by the BCL_GBI_ioTraceHandler functionto the default.

[Name]

-   -   BCL_GBI_ioTraceResetHandler        [Syntax]    -   void BCL_GBI_ioTraceResetHandler(void);        [Argument]    -   None        [Return Value]    -   None        C.5.1.15 Default Trace Function Execution (Non-disclosure)

Executes the default trace function from a trace function registered bythe BCL_GBI_ioTraceHandler function.

[Name]

-   -   BCL_GBI_ioTraceExecuteDefaultHandler        [Syntax]    -   void BCL_GBI_ioTraceExecuteDefaultHandler(int cmd, unsigned int        address, int data, void *arg);        [Argument]    -   cmd Function to be traced    -   address Address to be traced    -   data Data to be traced    -   arg Argument that was given to trace handler        [Return Value]    -   None        Industrial applicability

As described above, according to the present invention, there isprovided the test emulator, the test module emulator, and the recordmedium storing the programs for emulating appropriately the testapparatus which is used with various modules.

1. A test emulator for emulating a test apparatus comprising a pluralityof test modules for supplying a test signal to devices under testrespectively, comprising: a plurality of test module emulation sectionsfor emulating the plurality of test modules generating the test signalbased on different cycles; a control emulation section for emulating acontrol apparatus for controlling the test of the devices under test; asynchronous emulation section for generating test signal generatingtimings, at which each of said plurality of test module emulationsections is to generate the test signal in simulation corresponding tocycle time of said test module emulation section, based on instructionsfrom said control emulation section; a timing alignment section foraligning the plurality of test signal generating timings generated bysaid synchronous emulation section in order of time, and outputting themone by one; and a schedule section for causing said test moduleemulation section corresponding to one of the test signal generatingtimings output by said timing alignment section to generate the testsignal in simulation in the cycle time corresponding to the test signalgenerating timing.
 2. The test emulator as claimed in claim 1, furthercomprising a device under test simulating section for simulatingoperation of a device under test based on the test signal generated insimulation.
 3. The test emulator as claimed in claim 1, wherein saidsynchronous emulation section further generates interruption collectiontimings for collecting interruption to the control apparatus generatedin simulation by each of said plurality of test module emulationsections during the generation of the test signal in the cycle timecorresponding to the test signal generating timings, said timingalignment section aligns the plurality of test signal generating timingsand the plurality of interruption collection timings in order of time,and outputs them one by one, and said schedule section causes said testmodule emulation section corresponding to the interruption collectiontiming to notify said control emulation section of the interruptiongenerated in simulation in the cycle time at which said test moduleemulation section generates the test signal just before the interruptioncollection timing, in case that said timing alignment section outputsone of the interruption collection timings.
 4. The test emulator asclaimed in claim 1, wherein each of said plurality of test moduleemulation sections generates change timing of the test signal in thecycle time at the generation of the test signal in the cycle timecorresponding to the test signal generating timing, and the testemulator further comprises a DUT connection section for acquiring theplurality of change timings generated by said plurality of test moduleemulation sections, and for changing the test signal in simulation oneby one in order of time based on the plurality of change timings.
 5. Thetest emulator as claimed in claim 4, wherein said DUT connection sectionsupplies the plurality of change timings acquired from said plurality oftest module emulation sections to said timing alignment section, saidtiming alignment section aligns the plurality of change timings, theplurality of test signal generating timings, and the plurality ofinterruption collection timings in order of time, and outputs them oneby one, and said schedule section causes said DUT connection section tochange the test signal in simulation at the change timing, in case thatsaid timing alignment section outputs one of the change timings.
 6. Thetest emulator as claimed in claim 1, wherein each of said plurality ofsaid test module emulation sections notifies said synchronous emulationsection of the cycle end timing at which the cycle time ends during thegeneration of the test signal in the cycle time corresponding to thetest signal generating timing, and said synchronous emulation sectiongenerates the test signal generating timings at which said test moduleemulation section generates the test signal in simulation correspondingto next cycle time based on the cycle end timing notified from each ofsaid plurality of test module emulation sections.
 7. The test emulatoras claimed in claim 6, wherein said schedule section causes theinterruption generated in simulation by said test module emulationsection corresponding to the test signal generating timing to benotified to said control emulation section during the generation of thetest signal in the cycle time just before the test signal generatingtiming, in case that said timing alignment section outputs the testsignal generating timing corresponding to the next cycle time.
 8. Thetest emulator as claimed in claim 1, wherein each of said plurality oftest module emulation sections is realized by operating test moduleemulation program corresponding to said test module emulation section bya computer, and the test module emulation program comprises: a pluralityof hardware emulation functions, being provided corresponding to aplurality of commands received by the test module from said controlapparatus respectively, for emulating operation of the test modulecorresponding to the command; and a control function used in order forsaid schedule section to cause the test emulator to generate the testsignal in the cycle time corresponding to the test signal generatingtiming.
 9. A record medium storing therein program for causing acomputer to function as a test emulator for emulating test apparatusescomprising a plurality of test modules for supplying test signal todevices under test respectively, wherein the program causes the computerto function as: a plurality of test module emulation sections foremulating the plurality of test modules generating the test signal basedon different cycles; a control emulation section for emulating a controlapparatus for controlling the test of the devices under test; asynchronous emulation section for generating test signal generatingtimings, at which each of said plurality of test module emulationsections is to generate the test signal in simulation corresponding tocycle time of said test module emulation section, based on instructionsfrom said control emulation section; a timing alignment section foraligning the plurality of test signal generating timings generated bysaid synchronous emulation section in order of time, and outputting themone by one; and a schedule section for causing said test moduleemulation section corresponding to one of the test signal generatingtimings output by said timing alignment section to generate the testsignal in simulation in the cycle time corresponding to the test signalgenerating timing.
 10. A test module emulator for emulating a testmodule among a plurality of test modules by a test emulator foremulating test apparatuses comprising the plurality of test modules forsupplying test signal to devices under test respectively based on adifferent cycle, wherein the test emulator comprises: a controlemulation section for emulating a control apparatus for controlling thetest of the devices under test; a synchronous emulation section forgenerating test signal generating timings, at which each of saidplurality of test module emulation sections is to generate the testsignal in simulation corresponding to cycle time of said test moduleemulation section, based on instructions from said control emulationsection; a timing alignment section for aligning the plurality of testsignal generating timings generated by said synchronous emulationsection in order of time, and outputting them one by one; and a schedulesection for causing said test module emulation section corresponding toone of the test signal generating timings output by said timingalignment section to generate the test signal in simulation in the cycletime corresponding to the test signal generating timing, and the testmodule emulator comprises a pattern generator emulation section forgenerating the test signal in simulation in the cycle time correspondingto one of the test signal generating timings based on instructions fromsaid schedule section.
 11. The test module emulator as claimed in claim10, further comprising a test module interface emulation section fornotifying a synchronous emulation section of cycle end timing at whichthe cycle corresponding to one of the test signal generating timingsends, and causing said synchronous emulation section to further generatethe test signal generating timing at which the test module emulator isto generate the test signal in simulation for the next time based on thecycle end timing.
 12. A record medium storing therein program forcausing a computer to function as a test module emulator for emulating atest module among a plurality of test modules as for a test emulator foremulating test apparatuses comprising the plurality of test modules forsupplying test signal to devices under test respectively based on adifferent cycle, wherein the test emulator comprises: a controlemulation section for emulating a control apparatus for controlling thetest of the devices under test; a synchronous emulation section forgenerating test signal generating timings, at which each of saidplurality of test module emulation sections is to generate the testsignal in simulation corresponding to cycle time of said test moduleemulation section, based on instructions from said control emulationsection; a timing alignment section for aligning the plurality of testsignal generating timings generated by said synchronous emulationsection in order of time, and outputting them one by one; and a schedulesection for causing said test module emulation section corresponding toone of the test signal generating timings output by said timingalignment section to generate the test signal in simulation in the cycletime corresponding to the test signal generating timing, and the programcauses the computer to function as a pattern generator emulation sectionfor generating the test signal in simulation in the cycle timecorresponding to one of the test signal generating timings based oninstructions from said schedule section.
 13. A test apparatus comprisinga test module for supplying a test signal to a device under test,comprising: a control apparatus for controlling a test of the deviceunder test; a test module for generating a test signal based on a cycle;and a test module emulation section for emulating said test module,wherein said control apparatus inputs an instruction about which of areal test or a simulation test is to be selected for the test of thedevice under test, said control apparatus supplies said test module witha test program for testing the device under test and causes said testmodule to test the device under test when the instruction indicates thatthe real test of the device under test is to be performed, and saidcontrol apparatus supplies said test module emulation section with atest program for testing the device under test and causes said testmodule emulation section to simulate the test of the device under testwhen the instructions indicates that the simulation test of the deviceunder test is to be performed.
 14. The test apparatus as claimed inclaim 13, wherein said control unit executes communication software forperforming communication processing between said control unit and saidtest module, and said communication software decides whether the testprogram is to be supplied to said test module or said test moduleemulation section based on the instructions included in calling forinitializing the communication software in cooperation with said controlapparatus.
 15. A test emulator for emulating a test apparatus comprisinga plurality of test modules for supplying a test signal to devices undertest, comprising: a plurality of test module emulation sections foremulating the plurality of test modules generating the test signal basedon a cycle; a control emulation section for emulating a controlapparatus for controlling the test of the devices under test; and aschedule section for scheduling test signal generating timing at whicheach of said plurality of test module emulation sections is to generatetest signal corresponding to a cycle time in simulation, wherein saidtest module emulation section outputs variation of voltage of the testsignal during the cycle time corresponding to the test signal generatingtiming by calling voltage setting method of an output channel objectwhich emulates an output channel for multiple times on receiving thetest signal generating timing by a function call, and said test moduleemulation section notifies that output of the variation of the voltageof the test signal corresponding to the cycle time is finished bycalling an end method of the output channel object output after theoutput of the variation of the voltage of the test signal correspondingto the cycle time is finished.
 16. The test emulator as claimed in claim15, wherein said schedule section calculates a period during which allof said test module emulation sections finishes the output of thevariation of the voltage of the test signal based on the end methodnotified from each of said plurality of test module emulation sections,and the test emulator further comprises a device under test simulatingsection for acquiring the test signal within the period and simulatesoperation of the device under test during the period based on the testsignal.
 17. The test emulator as claimed in claim 15, wherein the outputchannel object forbids the variation of the voltage in the period duringwhich the output of the variation of the voltage of the test signal wasfinished, which was notified by the end method, after the end method wascalled.